http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #15 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
--- 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 re
--- 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 ab
--- 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 th
--- 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 sho
--- 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 #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 #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
thro
--- 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:
http://www.hpl.hp.com/research/linux
--- 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 #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 #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 #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.
--- 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
16 matches
Mail list logo
