This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: Tom Tromey <tromey at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: "Alfred M. Szmidt" <ams at gnu dot org>, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Mon, 04 Nov 2013 10:13:04 -0700
- 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> <E1Vd3d0-0005vw-59 at fencepost dot gnu dot org> <20131103220632 dot GC29825 at domone dot podge>
>>>>> "OndÅej" == OndÅej BÃlka <neleai@seznam.cz> writes:
OndÅej> Also to part it work, to quote ulrich:
OndÅej> "mcheck does not work for multi-threaded code. It cannot possibly do.
OndÅej> There is no way to fix this with the technology underlying mcheck."
OndÅej> which speaks for itself as one can write a standalone portable leak
OndÅej> detector that is faster, supports multithreading and does not need
OndÅej> modification of binary in weekend.
The above statement is true of the way mcheck is currently implemented.
Nothing says that it has to be implemented this way, though, or that
"son of mcheck" couldn't be done better.
In gdb we enabled mcheck by default for development builds, when it was
found on the host system. This caught real bugs during testing and was
cheap enough to simply enable all the time.
However we had to disable it once we allows multi-threading with Python.
This was a real loss.
Running the test suite under valgrind also has caught bugs, but it is
too slow to always be enabled.
So from our perspective, mcheck is a useful feature, which could be
improved. We wish it were.
Tom