LeakSanitizer fails based on stack layout

[llvmbot]

Bugzilla Link	43587
Version	9.0
OS	Linux
Attachments	demonstration and further details
Reporter	LLVM Bugzilla Contributor
CC	@vit9696,@vitalybuka

Extended Description

LeakSanitizer may fail to catch leaked memory based on stack layout.

While I did not perform any extensive research, I did verify that stack layout is the only changing factor in my compiled binaries by disassembly comparison. I did not verify whether the underlying issue can cause other problems than the one described by this report.

Please find attached a C program with comments about the verified environments and different ways to reproduce.

[vitalybuka]

I afraid it's work as intended.

LeakSanitizer scans stack for pointers. It's possible that old frame with dead pointers (main here) overlapped by new frame which does not use bytes with pointers. For leak sanitizer this looks like alive pointers in useful flame, so no leak.

To fix this we can clean stack on return, but it's going to hit performance.

[llvmbot]

Thank you very much for your explaination.

I won't pretend to know how LeakSan works, and especially not how it should work, but if I understood it correctly, it does solely by stack analysis. Is it too expensive to keep track of all mallocs? While that obviously does not allow tracing, it at least would give an indicator at termination that there is a leak at all.

[vitalybuka]

LSAN tracks all mallocs.
But it must not report stuff which is not leak. E.g. pointer in global variable is not considered a leak even on termination.

Maybe ignoring some pointers from main thread doing final leak-checking will work.

[llvmbot]

While programs keeping allocations alive past the termination of the entry point is a valid concept, I think the majority expects to be purged entirely, especially when not release software itself is sanitized but specific function calls from unit test applications. Can the data segment be scanned in the way the stack is?

I'd imagine there could be 1) a compilation switch to toggle whitelisting all global pointers and/or 2) a way to explicitly flag whitelisted pointers (i.e. alarm on all dangling allocations not referenced by a whitelisted pointer when main terminates). I do not know about implementation difficulties, so please excuse me if this is not feasible.

For instance, in a project I am contributing to, we have small unit test applications that call library functions from the main project and are both fuzzed and sanitized simultaneously and are not supposed to leave anything alive after termination. It would be invaluable to us to be notified about all leaked memory.