On Wed, Mar 18, 2009 at 09:53:58AM -0700, Arun Sharma wrote: > The malloc debugger (mpatrol?) is implemented as a wrapper around the > "real malloc". When a recursive call is detected, you avoid calling > libunwind and call the real malloc directly. This way the real malloc > is never called recursively.
Yes, it's mpatrol. However, it provides its own malloc. We avoid the libunwind call when already inside any mpatrol entry point, because a backtrace was already obtained at entry. The entire allocator is not reentrant, but we call libunwind very early on, so at that point it is effectively reentrant. > The use case for google-perftools is that the call to libunwind comes > from deep within the real malloc (tcmalloc in our case). The recursive > call hits a deadlock very quickly because the code is not reentrant. > Also, this is a performance sensitive code path. I'm not sure if > another check (for recursion) would be accepted by the maintainers. Yes, that part is believable. You mentioned something about memory pools; perhaps that's the answer. -- Daniel Jacobowitz CodeSourcery _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
