This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

debugging mallocs and per-thread tcache


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]