Re: RFC: api to walk memory allocations

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Oct 30, 2013 at 04:30:59PM -0600, David Ahern wrote:
> We are exploring options for debugging memory corruption and leaks.
> One of the ideas involves walking allocations and extending glibc
> with a generic hook for that. Before we get too far down this road I
> wanted to get thoughts from the glibc maintainers on the idea and
> whether such an extension would be accepted into glibc.
> 
> The API we have discussed is:
> [...]
> 
> The idea here is to have something that can be used within gdb as
> well as something that could be invoked runtime for a live dump. Any
> feedback on the idea would be appreciated.

My view is that this kind of invasive, heavy debugging interface does
not belong in glibc or anywhere it's introspective, but as part of the
debugger. Valgrind already does a great job with this kind of thing,
and gdb could do some similar work just by breakpointing malloc and
free and recording the calls. However, that's just my opinion and
certainly not authoritative for glibc.

BTW, I understand that you may want to be able to do this kind of
debugging on a core dump or a running application that was not
originally started in the debugger (in which case the gdb recording
approach would not work), but I don't think committing glibc to
maintaining this degree of meta-data overhead when not debugging is a
reasonable long-term constraint. Even if it's easy to implement with
the current malloc implementation (I doubt it is; generally, only free
chunks, not allocated chunks, are tracked in an efficient malloc
implementation), requiring the tracking would place constraints on
what sorts of optimizations could be made in the future.

Rich