This is the mail archive of the
mailing list for the glibc project.
debugging mallocs and per-thread tcache
- From: Tom Horsley <horsley1953 at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Thu, 30 Nov 2017 15:32:42 -0500
- Subject: debugging mallocs and per-thread tcache
- Authentication-results: sourceware.org; auth=none
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?