Re: debugging mallocs and per-thread tcache

[Carlos O'Donell <carlos at redhat dot com>]

On 11/30/2017 03:49 PM, Tom Horsley wrote:
> On Thu, 30 Nov 2017 15:27:11 -0800
> Carlos O'Donell wrote:
> 
>> All that the debugging malloc cares about in most cases is tracking
>> it's own API calls and ensuring you followed the allocation rules.
> 
> I should have said. This debug malloc basically does nothing
> but bookkeeping about the allocated block. It intercepts the
> public entry points to do the data gathering, then calls the
> original malloc routines.

That is OK.

> This way the behaviour of the program being debugged is as
> near identical as I can get it to the non-debugged program,
> but I can find things like the walkback for where blocks
> were allocated or freed (as one example of the useful data
> I can gather).

That is also OK.

The call to __libc_free() in tcache_thread_freeres is unobservable
by an external interposed library.

The tcache_thread_freeres call to __libc_free() is specifically
designed to jump to __libc_free without going through the PLT.
Any call to the internal name e.g. __libc_free, skips the PLT and
therefore cannot be interposed or observed. This is what the
libc_hidden_proto and libc_hidden_def declarations do.

So the interposing debug malloc can only see that malloc() is called,
this action internally fills the tcache, a subsequent free() frees
the allocated block back into the filled tcache, and then at
thread exit the tcache is released back to the free list. The only
operations the interposer can observe are the matching malloc/free.

Does that answer your question?

-- 
Cheers,
Carlos.