This is the mail archive of the 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 30 October 2013 17:41, Rich Felker <> wrote:
> 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.

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

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

SystemTap could be another option for implementing this type of thing.

Will Newton
Toolchain Working Group, Linaro

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