public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, <mcheck.h>
Date: Thu, 17 Nov 2016 16:08:00 -0000	[thread overview]
Message-ID: <468c5aa5-8ce2-7fa3-fa35-d665069f4ed9@linaro.org> (raw)
In-Reply-To: <DM5PR11MB1531D18AC2106506EE2F4285BBB10@DM5PR11MB1531.namprd11.prod.outlook.com>



On 17/11/2016 12:50, Steve Vormwald wrote:
> On 11/17/2016 08:00 AM, Florian Weimer wrote:
>> In my experience, it is not useful at all for finding the cause of leaks
>> because you only get the address of the immediate caller of malloc,
>> which is often a wrapper.  The address is subject to ASLR as well.
>>
>> Based on the comments in this thread, I'm not sure if people find mtrace
>> theoretically useful, or actually use it. :)
> 
> I make use of mtrace extensively when debugging oomkills on Cray
> systems.  Traditional memory leaks are typically not as big a problem as
> heap fragmentation.  Special hardware needs require non-default
> mallopt settings, notably severly restricting use of mmap, so fragmentation
> is a much larger problem for us than for many others.  In my experience,
> mtrace is lightweight enough to not noticeably perturb the heap structure
> over the course of the program, usually allowing me to pinpoint which allocations
> are leading to fragmentation.  Heavier instrumentation, such as valgrind,
> messes with it far too much to isolate which allocations from the application
> are actually causing fragmentation when the instrumentation is not present,
> making them much less useful to me.
> 
>> In my proposed NEWS entry, I forgot to mention Address Sanitizer (as was
>> pointed out in the GDB discussion).  It has leak detection capabilities
>> as well:
>>
>> ==7440==ERROR: LeakSanitizer: detected memory leaks
>>
>> Direct leak of 32 byte(s) in 1 object(s) allocated from:
>>     #0 0x7fc52f77097a in malloc (/lib64/libasan.so.2+0x9897a)
>>     #1 0x400703 in main (/tmp/a.out+0x400703)
>>     #2 0x7fc52f33757f in __libc_start_main (/lib64/libc.so.6+0x2057f)
>>
>> And it runs significantly faster than valgrind.
> 
> Does it have a noticeable impact on the layout of the heap compared to
> non-instrumented runs?

Yes, since it is built on ASAN it uses an interposed malloc implementation
and it also uses more VMA (as shadow memory for internal error detection).

  reply	other threads:[~2016-11-17 16:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 15:02 Florian Weimer
2016-10-26 15:55 ` Joseph Myers
2016-11-15 13:22   ` Florian Weimer
2016-11-15 15:39     ` Joseph Myers
2016-11-15 15:56       ` Florian Weimer
2016-11-16  1:37         ` Joseph Myers
2016-11-16  9:46           ` Will Newton
2016-11-17 13:00           ` Florian Weimer
2016-11-17 14:27             ` Joseph Myers
2016-11-17 14:50             ` Steve Vormwald
2016-11-17 16:08               ` Adhemerval Zanella [this message]
2016-11-18  9:13               ` Florian Weimer
2016-11-18 17:29                 ` Steve Vormwald
2016-11-21 19:43                   ` DJ Delorie
2016-11-22 15:12 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=468c5aa5-8ce2-7fa3-fa35-d665069f4ed9@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).