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

[Florian Weimer <fweimer@redhat.com>]

On 11/16/2016 02:36 AM, Joseph Myers wrote:
> On Tue, 15 Nov 2016, Florian Weimer wrote:
>
>>> I don't consider valgrind suitable for replacing the uses of mtrace in the
>>> glibc testsuite (or other similar uses elsewhere for lightweight checking
>>> for leaks).
>>
>> I completely agree.
>>
>> The above is for the NEWS file, for external use.  For internal use, we still
>> need a solution.  (I have an mtrace-compatible interposition-based tracer
>> almost finished, but it may not make the cut for the next release, and it may
>> be superseded by DJ's work anyway.)  I think we can run internal deprecation
>> at a different pace than external deprecation.
>
> Well, I think mtrace (meaning the ability to run with tracing then run the
> mtrace script to process the results, more than the functions to turn
> tracing on and off) is similarly useful externally as a lightweight system
> for tracing allocations and detecting leaks.  And it is of course
> documented in the manual.

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

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.

Florian