[Libunwind-devel] Re: Call to strdup breaks heap profilers

[Arun Sharma]

On Wed, Mar 18, 2009 at 6:42 AM, Daniel Jacobowitz <address@hidden> 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