This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: "Alfred M. Szmidt" <ams at gnu dot org>, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Mon, 4 Nov 2013 21:35:01 +0100
- 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> <87iow8t7j3 dot fsf at fleche dot redhat dot com>
On Mon, Nov 04, 2013 at 10:13:04AM -0700, Tom Tromey wrote:
> >>>>> "OndÅej" == OndÅej BÃlka <email@example.com> 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.
I am writing checker that is more capable, now it detects double free,
writing before/past array, a version to emulate mtrace is here.
it is mostly lacking error reporting, for illegal writes it aborts, for
reporting leaks I could extract call address but turning them to
file/line pair is ugly.
One alternative would be could allocations and for leaks print
watchpoints that will stop at these allocations.
For leaks it would be handy to know layout of static data to filter
allocations that are still reachable. As gdb can extract these from
debug information problem is how to make accessible to leak detector.
Also a gdb could benefit from this allocator as it could for given
address in heap tell lower and upper bound of allocated area.
> 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.