http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
--- Comment #13 from rth at gcc dot gnu dot org 2010-08-04 23:08 ---
There are two solutions to this:
(1) Make sure your binary provides PT_GNU_EH_FRAME. This is the quickest
path through the unwinder, since the table is pre-sorted by the linker.
(2) Have your malloc detect the
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:23 ---
What is your malloc doing special and why would it dead lock? (if you are
throwing from inside malloc I think that is an invalid thing to do).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- 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.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 00:51 ---
You know that glibc has an backtrace function which might be more friendly for
your purpose?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 00:53 ---
I really doubt we can remove it because this is also used in the undwinding for
exceptions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- 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
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 01:02 ---
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:
--- 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
--- 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:
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-08 01:10 ---
(In reply to comment #8)
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.
Yes and the ones against
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-08 01:12
---
(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
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-08 01:23
---
(In reply to comment #7)
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?
If you do
--- 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
16 matches
Mail list logo
