Open znkr opened 1 month ago
I don't think this has to be a proposal, taking it out of the proposal process. We should just do this as part of our ordinary sanitizer support.
It sounds like this will be pretty loose, unless there is some way to tell the sanitizer which pointers are live. But a conservative leak detector is still better than no leak detector at all.
I took another look into LSAN, to understand how conservative it would be. https://maskray.me/blog/2023-02-12-all-about-leak-sanitizer was quite helpful. What that article doesn't document is the use_poisoned
flag. IIUC, LSAN can use ASAN poisoning information when scanning for pointers and will ignore pointers in poisoned memory. I think that Go already poisons freed memory, so it might be possible to make this pretty accurate.
It's a completely redundant feature, the example code doesn't detect the array size at all, and of course it's also your freedom, so why should you be reminded of it
Proposal Details
This is follow-up to #44853 which proposed to enable ASAN for Go.
One type of error in Go / C interop are memory leaks. These can be detected by ASAN using
ASAN_OPTIONS=detect_leaks=1
. Unfortunately, this doesn't fully work with Go's ASAN integration. For example, allocating a C object and storing it in a global variable in Go is detected as a leak.I believe to make LSAN work, all we need to do is to tell it about memory regions that Go manages to consider as roots using
__lsan_register_root_region
.