llvm dev - Nov 2015 - Docs for leak checker (and other sanitizers)?

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!

> 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.

-- 
greg

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

On Wed, Nov 11, 2015 at 3:00 PM, Greg Stark <stark at mit.edu> wrote:
> 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?

No, we never implemented that.
Feel free to file a bug (I don't think we have one), but no promises here.

> It looks like msan does
> have this, __msan_allocated_memory()
>
Correct.
msan has significantly different layout of metadata and so it was easier to
implement (and more important)

>
> 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.
>
Maybe you can just use suppressions for that?

You can also try to call __lsan_disable() very early at start up and then
  __lsan_enable() before fuzzing.

hth,

--kcc

>
> --
> greg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/a6c1705e/attachment.html>