This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Alfred M. Szmidt" <ams at gnu dot org>
- Cc: joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Sun, 3 Nov 2013 23:06:32 +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>
On Sun, Nov 03, 2013 at 02:46:30PM -0500, Alfred M. Szmidt wrote:
>
> mtrace has its uses, it works, and people use is... Why deprecate a
> useful tool?
To know if something is deprecated you do not ask a question if it is
useful but a question if there is alternative that is better in most
areas.
You could on base of usefullness argue that you can ride a horse
as useful way of transport so people should learn riding a horse.
As finding leaks with valgrind is easier as it shows full backtrace,
does not show false positives like mtrace does and identified illegal
memory access you wasted time by learning mtrace when you should learn
valgrind anyway.
Also to part it work, to quote ulrich:
"mcheck does not work for multi-threaded code. It cannot possibly do.
There is no way to fix this with the technology underlying mcheck."
which speaks for itself as one can write a standalone portable leak
detector that is faster, supports multithreading and does not need
modification of binary in weekend.