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

Enabling the leak sanitizer would be a nice improvement. Note that some (see list) Go projects are already sidestepping this limitation by manually calling __lsan_do_leak_check at program exit.

Does anybody happen to know which versions of clang and GCC added support for __lsan_do_leak_check? Can we just assume it is present?

Does anybody happen to know which versions of clang and GCC added support for __lsan_do_leak_check? Can we just assume it is present?

LLVM introduced it in version 3.4 (source), which was released in 2015. GCC followed suite in version 5 (source), released also in 2015.

I've been using __lsan_do_leak_check for a while with great results, catching real memory leaks in production. You can see its useful by executing the following sample with go run -asan .:

package main

// void __lsan_do_leak_check(void);
import "C"

func main() {
	defer C.__lsan_do_leak_check()
	C.CString("foo")
}

Which on my machine outputs:

=================================================================
==13248==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7f127460a24f in malloc (/usr/lib/libasan.so.8+0xe124f) (BuildId: ccf997b37481b6e7b757519a36b110bee0a850cd)
    #1 0x472c7b  (/tmp/go-build1729442831/b001/exe/test+0x472c7b) (BuildId: 2adb13e01facb758d13955e5fc42872f5ec67f1f)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
exit status 1

Note that the memory leak sanitizer is enabled by default on Linux when using the address sanitizer, so Go apps built with -asan are already tracking down memory leaks. The problem is that these are not reported because atexit doesn't work with cgo (see #5948), and the address sanitizer registers __lsan_do_leak_check using atexit (source). My bet is that is we fix atexit, then the memory leak detector will start reporting memory leaks without any additional change. If that's too much work, then manually calling __lsan_do_leak_check when the Go runtime is exiting is also an option.

Change https://go.dev/cl/651755 mentions this issue: runtime: in asan mode call __lsan_do_leak_check when exiting

Change https://go.dev/cl/659135 mentions this issue: runtime: in asan mode unregister root regions on free