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: [RFC] Deprecating mtrace?


On Mon, Nov 04, 2013 at 10:28:38AM +0100, Florian Weimer wrote:
> On 11/03/2013 08:17 PM, OndÅej BÃlka wrote:
> 
> >Please state which are platforms that are supported by glibc and
> >improtant programs running only on that platform needs mtrace
> 
> Does Emacs now run without unexec'ing?  That precluded using valgrind on it.
> 
> When I tracked down one rather prominent memory leak some time ago,
> mtrace was still useless because it only reported the address of
> Emacs' malloc wrapper, not the actual allocation site.  In the end,
> I had to use a LD_PRELOAD library to gather the data.
> 
That is among problems with threading and design that is just braindead
another reason why use something better than mtrace.

Creating faster leak detector is easy, you just keep a double linked
list of allocations and print what is left at end.

That is what I done in my simple leak detector that I attached.

If somebody wants mtrace/untrace to enable which allocations to trace
this is also easy, just add a flag for each allocation and print only
these that have flag set.

Attachment: leak_detector.c
Description: Text document


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