Valgrind also does stuff like memory tracking and memory-profiling, so this is great also from a performance tracking point of view.

Go doesn't use clang/llvm, so they can't use these tools.

TinyGo does, but it is also behind in language support.

Go has had its own version of msan and asan for years at this point.

Valgrind is way faster and can be attached to a running program.

Programs running under any Valgrind tool will be executed using a CPU emulator, making it quite a bit slower than, say, running the instrumented binaries as required by sanitizers; it's often an order of magnitude slower, but could be very well be close to two orders of magnitude slower in some cases. This also means that it just can't be attached to any running program, because, well, it's emulating a whole CPU to track everything it can.

(Valgrind using a CPU emulator allows for a lot of interesting things, such as also emulating cache behavior and whatnot; it may be slow and have other drawbacks -- it has to be updated every time the instruction set adds a new instruction for instance -- but it's able to do things that aren't usually possible otherwise precisely because it has a CPU emulator!)

You're right and I was wrong, but in my experience Valgrind has been way faster then the AdressSanitizer. I don't perceive a difference with Valgrind, while ASan makes the program slower around 10x.

I'm interested too. I'm using a Go program that call a cpp library with SWING and I was interested in find out if that library had a memory leak, or maybe the SWING wrap I wrote. But this kind of problem can't be detected via pprof, so I tought, what if Go support Valgrind?? and find out this changes.

I'm not sure if this will work though, will it @bracewel?