> I think the newer version of libunwind still have the malloc calls,
> and it's difficult to rremove them.  But this is just a vague memory I
> have of what someone told me, and may be totally inaccurate!  It would
> be great if the newer versions worked.

> On Sep 19, 1:35 pm, Craig Silverstein <csilv...@google.com> wrote:
> > } I am curious if anyone knows whether these new releases fix the
> > } crashes?

> > I think the newer version of libunwind still have the malloc calls,
> > and it's difficult to rremove them.  But this is just a vague memory I
> > have of what someone told me, and may be totally inaccurate!  It would
> > be great if the newer versions worked.

> There are tests in libunwind that try to catch unintentional calls to
> malloc and friends from within libunwind.

> Ubuntu 11.04 (amd64) + libunwind 1.0.1:

> tests/Ltest-nomalloc: pass
> tests/Ltest-nocalloc: fail

> There is a simple fix for Ltest-nocalloc failure:

> --- a/tests/Gtest-nocalloc.c
> +++ b/tests/Gtest-nocalloc.c
> @@ -123,6 +123,8 @@ main (int argc, char **argv)
>      if (pthread_key_create (&key, NULL))
>        panic ("FAILURE: unable to create key %d\n", i);
>    }
> +  do_backtrace();
> +  num_mallocs = num_callocs = 0;
>    foo1 ();
>    num_errors = num_mallocs + num_callocs;
>    if (num_errors > 0)

> That is, if you insert a dummy call to backtrace() from your thread
> creation routine, libunwind per-thread state gets initialized once and
> there should be no further calls to (libunwind ->
> pthread_setspecific() -> calloc()) from within libunwind.

> The other common problem people run into using libunwind on x86_64 is
> that dl_iterate_phdr() is not async signal safe. That routine uses
> locks and could potentially call malloc. No good solution in sight,
> other than hacking your libc and implementing a version that doesn't
> do both of the above.

>  -Arun