This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Florian Weimer <fweimer at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 04 Nov 2013 10:30:11 -0500
- Subject: Re: [RFC] Deprecating mtrace?
- Authentication-results: sourceware.org; auth=none
- References: <20131103185737 dot GA29145 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1311031859260 dot 16907 at digraph dot polyomino dot org dot uk> <20131103191754 dot GA29265 at domone dot podge> <527768C6 dot 5030008 at redhat dot com> <20131104130504 dot GB6647 at domone dot podge>
On 11/04/2013 08:05 AM, OndÅej BÃlka wrote:
> 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.
All of this suggests to me that we need a an mtrace-compatible
replacement that is thread-safe. Nobody has investigated this in
detail and it would be a useful project.