On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor i...@google.com wrote:
I think that the libgcc unwinder only calls malloc if somebody calls
__register_frame_info.
So I looked. Indeed it doesn't call malloc in our environment, but
does call dl_iterate_phdr, which is just as deadly.
To be
On Thu, Feb 28, 2013 at 8:23 AM, Paul Pluzhnikov ppluzhni...@google.com wrote:
On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor i...@google.com wrote:
I think that the libgcc unwinder only calls malloc if somebody calls
__register_frame_info.
So I looked. Indeed it doesn't call malloc in
On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor i...@google.com wrote:
does call dl_iterate_phdr, which is just as deadly.
Hmmm, I guess I can't remember why.
Let me refresh your memory. You've seen this deadlock before:
Thread 1Thread 2
dlopen
On Thu, Feb 28, 2013 at 10:10 AM, Paul Pluzhnikov
ppluzhni...@google.com wrote:
On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor i...@google.com wrote:
does call dl_iterate_phdr, which is just as deadly.
Hmmm, I guess I can't remember why.
Let me refresh your memory. You've seen this
Thread 1Thread 2
dlopen malloc
... takes loader lock ... takes malloc lock
malloc _Unwind_Backtrace
... needs malloc lock dl_iterate_phdr
held by T2... needs loader lock held by T1
On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote:
Similarly, couldn't dlopen drop the loader lock while calling malloc?
It can't, but perhaps it could call some alternative malloc instead
(the simpler malloc version in ld.so or similar).
Jakub
On Thu, Feb 28, 2013 at 9:07 AM, Xinliang David Li davi...@google.com wrote:
Any insight about the relative performance of the two implementations?
We have a benchmark for the speed of unwinder. Here are results.
The number /1, /2, etc. is the number of levels in the stack trace.
Using
On Thu, Feb 28, 2013 at 11:59 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Feb 28, 2013 at 11:57:48AM -0800, Cary Coutant wrote:
Similarly, couldn't dlopen drop the loader lock while calling malloc?
It can't, but perhaps it could call some alternative malloc instead
(the simpler malloc
Greetings,
Google ref b/8187733
Build libstdc++-v3/src/c++11/debug.cc with -fno-omit-frame-pointer, so
frame-based unwinder can step through it.
Tested: bootstrap build and verified debug.cc is built with
-fno-omit-frame-pointer.
Ok for google/gcc-4_7 and google/integration?
Thanks,
--
Paul
On Wed, Feb 27, 2013 at 3:13 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:
Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
On Wed, Feb 27, 2013 at 12:13 PM, Paul Pluzhnikov
ppluzhni...@google.com wrote:
Greetings,
Google ref b/8187733
Build libstdc++-v3/src/c++11/debug.cc with -fno-omit-frame-pointer, so
frame-based unwinder can step through it.
Just an aside which program does not understand dwarf2 unwinding?
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link in a frame-based unwinder.
This allows us to report crashes and record runtime statistics from the
executable itself,
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link in a frame-based unwinder.
This allows us to report crashes and
On Wed, Feb 27, 2013 at 12:53 PM, Jeff Law l...@redhat.com wrote:
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski pins...@gmail.com wrote:
Just an aside which program does not understand dwarf2 unwinding?
All Google executables currently link
On 02/27/2013 02:46 PM, Andrew Pinski wrote:
Perf handles this by saving off some of the stack space instead and
then post-process it. This is why I said perf handles this case
already. Now oprofile does not but oprofile is really going away.
I'm well aware of how perf handles this, having had
On Wed, Feb 27, 2013 at 1:46 PM, Andrew Pinski pins...@gmail.com wrote:
libunwind is not needed since there is already a dwarf2 based unwinder
that is accessible in libgcc already.
Last I checked, libgcc dwarf handling code called malloc, and thus wasn't
suitable when you want to instrument
On Wed, Feb 27, 2013 at 2:01 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:
Last I checked, libgcc dwarf handling code called malloc, and thus wasn't
suitable when you want to instrument malloc *itself* to collect stack
traces, nor for SIGPROF profiling.
Is libgcc dwarf code async-signal
17 matches
Mail list logo
