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

[Daniel Jacobowitz]

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