On Wed, Mar 18, 2009 at 6:42 AM, Daniel Jacobowitz <[email protected]> wrote:
> Thanks for this. I'm sorry I wasn't able to get to it - part of > the reason is that I don't have a test setup for it any more. > The patches look entirely sane to me. > Thanks for taking a look. > For what it's worth, we use this code from malloc; there's a simple > recursion guard in the caller. I'd rather keep it enabled. But I do > not see an immediately obvious way to do it without malloc. Here's my understanding of how this works: 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. 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. -Arun _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
