This is the mail archive of the
mailing list for the glibc project.
Re: RFC: api to walk memory allocations
- From: Rich Felker <dalias at aerifal dot cx>
- To: David Ahern <dsahern at gmail dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 30 Oct 2013 23:31:30 -0400
- Subject: Re: RFC: api to walk memory allocations
- Authentication-results: sourceware.org; auth=none
- References: <527188A3 dot 4000305 at gmail dot com> <20131031004120 dot GF20515 at brightrain dot aerifal dot cx> <CANu=Dmj-8iEPgfA69yNmPNSxOXvX5u_SNSdUrNMJeipCG+Apqg at mail dot gmail dot com> <5271C9CE dot 1000409 at gmail dot com>
On Wed, Oct 30, 2013 at 09:09:02PM -0600, David Ahern wrote:
> >I agree. This type of thing has the habit of becoming an API and then
> >has to be supported which places restrictions on how malloc can be
> I was hoping this would be seen in the same light as mcheck and
> mtrace - but along the lines of something you can use in a
> production environment.
I guess some of us have higher standards for what goes into a
"production environment"... :-)
> I am talking about production systems that are up and running for
> months to years. You do not run gdb or valgrind or any other
> debugger in these scenarios - and that includes SystemTap,
> perf-probes, etc - for a process that can have millions of
> One scenario here is a customer suspects a memory leak in a process
> and runs a CLI command that essentially walks the memory data
> structures. With the callback we can run a sanity checker or what
> have you. There's more to it from an infra perspective, but that
> gets into ap design. glibc wise it is a matter of walking glibc data
> structures and allowing aps to have a means of sanity checking.
I'm not clear how much that really buys you. To debug the leak you
need a lot more information about the owners of the allocations, not
just the map of all existing allocations.
If you're really having problems with issues like this in production
code, a much better solution would be switching to something like
talloc that helps you manage hierarchical allocation ownership and
freeing, or some sort of automatic reference counting.
> We have discussed other options for what we need. I would prefer
> something builtin that leverages the existing data structures. No
> sense adding layers, complexity and overhead. We are not the only
> ones in need of a memory tracking, leak, corruption capability.
The problem with "leveraging existing data structures" is that it
locks you into the current existing data structures. Building as a
separate layer, or separate malloc implementation you could link in,
may cost more for users of this feature, but avoids the perpetual cost
for everyone else who doesn't need it.