[Bug c/24724] New: _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

As this stacktrace shows:

#3  0x004044e2 in malloc (size=36024) at tcmalloc.cc:1314
#4  0x0047a938 in search_object ()
#5  0x0047b189 in _Unwind_Find_FDE ()
#6  0x00478049 in uw_frame_state_for ()
#7  0x00478eca in uw_init_context_1 ()
#8  0x004790b0 in _Unwind_Backtrace ()

there are code paths from _Unwind_Backtrace to malloc. This makes the unwinder
deadlock prone when called from applications that have their own customized
malloc.


-- 
   Summary: _Unwind_Backtrace() calls malloc
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arun dot sharma at google dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

[Bug other/24724] _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

--- Comment #2 from arun dot sharma at google dot com  2005-11-08 00:48 
---

It deadlocks because malloc is holding a lock and then calls the unwinder.
No, we're not throwing exceptions. One reason why malloc might want to use the
unwinder is to do heap profiling.

http://goog-perftools.sourceforge.net/doc/heap_profiler.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

[Bug other/24724] _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

--- Comment #5 from arun dot sharma at google dot com  2005-11-08 00:55 
---
(In reply to comment #3)
 You know that glibc has an backtrace function which might be more friendly for
 your purpose?
 

glibc backtrace dlopens libgcc and uses _Unwind_Backtrace() on amd64. glibc
backtrace has it's own problems (i.e. mallocs) which is why we're not using it.

See: 

http://sources.redhat.com/bugzilla/show_bug.cgi?id=1579


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

[Bug other/24724] _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

--- Comment #7 from arun dot sharma at google dot com  2005-11-08 01:07 
---
(In reply to comment #4)
 I really doubt we can remove it because this is also used in the undwinding 
 for
 exceptions.
 

It must be possible to do stack unwinding without any mallocs. If the exception
throwing code path requires mallocs, that's fine by us.

The particular malloc in question is coming from start_fde_sort() in
unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before
_Unwind_Backtrace() is called?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

[Bug other/24724] _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

--- Comment #8 from arun dot sharma at google dot com  2005-11-08 01:09 
---
(In reply to comment #6)
 Hmm, You could try libunwind instead, it should work on x86_64:
 http://www.hpl.hp.com/research/linux/libunwind/
 
 They show you how to use libunwind to generate a normal backtrace:
 http://www.hpl.hp.com/research/linux/libunwind/man/libunwind(3).php
 
 Though I doubt that none of these will remove the use of malloc though.
 

libunwind doesn't pass unit tests on amd64. davidm thinks that the problems are
outside of libunwind. I think he has a couple of bugs open against gcc/glibc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

[Bug other/24724] _Unwind_Backtrace() calls malloc

[arun dot sharma at google dot com]

--- Comment #12 from arun dot sharma at google dot com  2005-11-08 01:30 
---
(In reply to comment #10)
 (In reply to comment #9)
  Yes and the ones against gcc are only about eplogue or prologue so it should
  not matter for what you are doing.
 
 PR 18748 and PR 18749 both are about prologue and eplogue code which should 
 not
 matter with the backtrace at all.
 

ok, will try to root cause our problems with libunwind (they show up as bad
pointer dereferences in libunwind) and get back to you.

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724