This is the mail archive of the
mailing list for the glibc project.
Re: debugging mallocs and per-thread tcache
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Tom Horsley <horsley1953 at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Sun, 3 Dec 2017 14:19:14 -0800
- Subject: Re: debugging mallocs and per-thread tcache
- Authentication-results: sourceware.org; auth=none
- References: <20171130153242.1503c6f8@tomh> <email@example.com> <20171130184920.684009ce@zooty> <firstname.lastname@example.org> <20171201074835.3b802377@tomh>
On 12/01/2017 04:48 AM, Tom Horsley wrote:
> On Thu, 30 Nov 2017 18:28:42 -0800
> Carlos O'Donell wrote:
>> Does that answer your question?
> Yep, it all makes sense now and explains what I am seeing.
> Aside from LD_PRELOAD, when integrated into our debugger
> the debug malloc can work by patching in code at the entry
> points to the libc malloc routines. Since that gets hit
> without going through .plt (which allows it to work in
> a static linked program) then I see the calls from the
> cleanup code.
> But if I can patch in code, I ought to be able to patch in
> a check for tcache_shutting_down true and ignore the error
> checking for free calls.
> Thanks for the explanation!
You are welcome. Please feel free to come back and ask any
We document malloc internals on the wiki here:
If there is anything that is missing from there, please
feel free to suggest some edits (which you can do yourself
if you go through the new wiki account process