This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: ams at gnu dot org (Alfred M. Szmidt)
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Sun, 03 Nov 2013 19:24:06 -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> <E1Vd3d0-0005vw-59 at fencepost dot gnu dot org> <20131103220632 dot GC29825 at domone dot podge>
- Reply-to: ams at gnu dot org
The usage cases between valgrind and mtrace are so vastly different
that which is better is a matter of what you are doing, there several
cases when valgrind simply cannot do the job. For example,
enabling/disabling leak tracing on a already running process, or when
you are only interested in parts of the code where you might suspect a
leak in a long running process, or enable tracing automatically when
you hit some trigger (e.g. memory usage exceeding some limit). Two
different tools, with two different goals, mtrace for programmatically
doing traces, and valgrind for interactive usage.