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

[Kostya Serebryany via llvm-dev]

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>