Re: debugging mallocs and per-thread tcache

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

On 11/30/2017 12:32 PM, Tom Horsley wrote:
> I'm currently baffled by what I'm seeing from a debugging
> malloc on a threaded program using the new tcache per-thread
> support in glibc.
> 
> If the debugger (for instance) uses the LD_PRELOAD technique
> to override the normal malloc entry points, when a thread
> exits, I get an infinite number of errors reporting free()
> calls on blocks that were never allocated.
> 
> I get the impression that all the tcache_entry objects
> are "malloced" without actually calling malloc, so the
> debug code never notices them being allocated, but then
> the thread cleanup hooks run and call the __libc_free
> on these chunks.
>
> Is that what is really going on?
> 
> How is a debug malloc supposed to know this stuff?
 
(1) A debugging malloc using LD_PRELOAD.

A debug malloc must replace *all* entry points into the malloc family
of API functions, and in doing so it is not using glibc malloc at all
anymore. The debug malloc has used LD_PRELOAD to interpose it's own
version of malloc. The glibc malloc is no longer in use by anything
in the process.

Why is tcache coming into play in this kind of scenario?

All that the debugging malloc cares about in most cases is tracking
it's own API calls and ensuring you followed the allocation rules.

The debugging malloc does not *need* to know anything about these
details.

(2) How does tcache work internally?

Yes, tcache hooks into the chunk scanner to get low-cost access to
chunks that it can use to fill the cache. Then at thread exit we do
call __libc_free (internal symbol) to place the valid chunk back
into the free list.

This should not impact any tooling. It doesn't cause any problems
for valgrind either.

-- 
Cheers,
Carlos.