This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Deprecating mtrace?
- From: Fabrice Bauzac <libnoon at gmail dot com>
- To: ams at gnu dot org
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, joseph at codesourcery dot com, libc-alpha at sourceware dot org
- Date: Mon, 4 Nov 2013 09:29:47 +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> <E1Vd7xe-0002K3-Pi at fencepost dot gnu dot org>
Valgrind is too slow for large CPU-intensive programs.
2013/11/4 Alfred M. Szmidt <ams@gnu.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.