This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: api to walk memory allocations


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
> >implemented.
> 
> 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
> allocations.
> 
> 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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]