On Thu, Feb 28, 2013 at 11:59 AM, Jakub Jelinek 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 version in l
On Thu, Feb 28, 2013 at 9:07 AM, Xinliang David Li 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 frame-based unwinder:
B
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
> 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
On Thu, Feb 28, 2013 at 10:10 AM, Paul Pluzhnikov
wrote:
> On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor 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 1
On Thu, Feb 28, 2013 at 9:28 AM, Ian Lance Taylor 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 malloc
..
On Thu, Feb 28, 2013 at 8:23 AM, Paul Pluzhnikov wrote:
> On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor 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
On Wed, Feb 27, 2013 at 5:52 PM, Ian Lance Taylor 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 fair, libunwind d
On Wed, Feb 27, 2013 at 2:01 PM, Paul Pluzhnikov 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 safe now?
> If no
On Wed, Feb 27, 2013 at 1:46 PM, Andrew Pinski 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 malloc *itself* to
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 12:53 PM, Jeff Law wrote:
> On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
>>
>> On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski wrote:
>>
>>> Just an aside which program does not understand dwarf2 unwinding?
>>
>>
>> All Google executables currently link in a frame-based
On 02/27/2013 01:50 PM, Paul Pluzhnikov wrote:
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski 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 statis
On Wed, Feb 27, 2013 at 12:17 PM, Andrew Pinski 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, in ways that are
On Wed, Feb 27, 2013 at 12:13 PM, Paul Pluzhnikov
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?
Perf is setup to
On Wed, Feb 27, 2013 at 3:13 PM, Paul Pluzhnikov wrote:
> Ok for google/gcc-4_7 and google/integration?
OK.
Diego.
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 P
17 matches
Mail list logo
