I'm using Ubuntu 18.04 with glibc-2.27, a distribution where the tcache re-allocation system is deployed. While debugging some image with gdb + gef (aka GDB Enhanced Features) I have noticed that the tcache bin is associated with an arena.
A generic heap bins command output look like this:
gef➤ heap bins
───────────── Tcachebins for arena 0x7ffff7dcfc40 ───────────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=0, size=0x10] count=1 ← Chunk(addr=0x555555756260, size=0x20, flags=PREV_INUSE)
As one can tell from the output, the tcache bins are associated with an arena. This looks odd to me, since the whole idea of tcache (at least the way I got it) was to avoid the race between threads which was caused by locking arenas.
I did some research of Malloc Internals at glibc wiki, and I found what I already knew:
Each thread has a per-thread cache (called the tcache) containing a small collection of chunks which can be accessed without needing to lock an arena.
So, what is the relationship between arenas and tcache bins? if I can access the tcache without locking an arena why gef print an arena (address)? Thanks for any clarification!
This appears to be a presentation issue in the GDB plugin. Instances of the tcache are associated with threads, not arenas. One tcache instance can contain allocations from multiple different arenas, not just the arena currently associated with the thread to which the tcache belongs.