Leaving some notes. I am able to reproduce a msan uninitialized failure when using the path of an obsolete file when it comes time to delete it.

Eventually I was able to reproduce on a gceworker with Ubuntu 24.04, with this docker container:

docker run --security-opt seccomp:unconfined --rm -it   -v "$PWD":/work -w /work   ghcr.io/christopherhx/runner-images:ubuntu24-runner-large-latest   bas

And this command

GOMAXPROCS=4 CC=clang go test -msan -tags 'invariants slowbuild' ./internal/metamorphic -run TestMetaCockroachKVs/execution/standard-012 -timeout 0 -v --exec 'stress -p 80 -maxruns 5000

I tried many variations of debugging messages and techniques. I am using this code to check if the data is poisoned and get more info (like stacks) before the failure:

/*
#include <sanitizer/msan_interface.h>
static inline long msan_test(const void* p, size_t n) {
  return __msan_test_shadow(p, n);   // -1 if clean, else offset of first poisoned byte
}
*/
import "C"
import "unsafe"

func TestString(s string) (firstPoison int) {
	if len(s) == 0 {
		return -1
	}
	p := unsafe.StringData(s)
	return int(C.msan_test(unsafe.Pointer(p), C.size_t(len(s))))
}

In most cases, the file path is unchanged even though msan detected some kind of copy from unininitialized data. I can safely print a string.Clone of it but printing the string directly causes the failure.
But in a single instance I saw the path show up as:

        path clone: �o]+��͵�🪳🪳

This is exactly the pebbleDBMagic at the end of ssts.

master: nightly linux-msan failed #5498

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions