[llvm-dev] Docs for leak checker (and other sanitizers)?

[Greg Stark via llvm-dev]

On Tue, Nov 10, 2015 at 5:43 PM, Greg Stark <stark at mit.edu> wrote:
> On Mon, Nov 9, 2015 at 7:20 PM, Kostya Serebryany <kcc at google.com> wrote:
>> Most likely, you need
>> https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer
>
> Thanks!

This was really helpful.

I have used __asan_poison_memory_region() but it's the call stack for
the allocation site is based on when malloc was called. This is a
random earlier allocation that allocated the pool that the chunk was
returned from. Is there an API to specify the block was just allocated
and to associate it with a new call stack? It looks like msan does
have this, __msan_allocated_memory()

I'm also struggling with a asan report I can't explain but I think
I'll write that up as a separate e-mail.

>> I don't think lsan supports this mode directly,
>> but why do you think that the init-time allocations are going to be
>> "leaked"?
>> If there is some object still pointing to those allocations lsan will not
>> complain.
>
> Hm. That's a good point. I'm not exactly sure how the ripcord
> allocator being used in Postgres combined with the asan
> poison/unpoison calls would actually appear to lsan. But even aside
> from that I believe there are allocations that are made early in
> server initialization that are never freed and it's considered not
> worth the book-keeping to free them due to the on-off nature of the
> initialization.

Yeah. Further investigation shows that a lot of command-line parsing
logic in both the main server and various other tools leak a lot of
small strings here and there. There are also a number of other
assorted small leaks during setup such as the SUS environ global which
can't be instrumented and so on.

The short story though is that in the fuzzer I just want to check that
I'm not leaking memory during the fuzzer loop. I don't want to embark
on the quest of eliminating memory leaks everywhere, especially during
system startup and utilities. That's probably the same workflow if I
wanted to use it to find leaks in the server processing loop too. I
would be pretty happy if there was a way to just clear the list of
allocations being tracked entirely and then start from that clean
slate.

-- 
greg