This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: debugging mallocs and per-thread tcache
- From: Tom Horsley <horsley1953 at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 1 Dec 2017 07:48:35 -0500
- Subject: Re: debugging mallocs and per-thread tcache
- Authentication-results: sourceware.org; auth=none
- References: <20171130153242.1503c6f8@tomh> <ccce334c-4a33-9a9c-638d-c0ff054d9a00@redhat.com> <20171130184920.684009ce@zooty> <aa4de310-366a-5d7f-c421-1d16b4efa2af@redhat.com>
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!