This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] malloc: Deprecate hook variables, __default_morecore, <mcheck.h>
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
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
==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.