This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, <mcheck.h>



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]