Re: Shark failing to get entire stack

On 13/11/2010 21:32, Mike Shaver wrote:
> On Sat, Nov 13, 2010 at 1:24 PM, Jonathan Watt <[email protected]> wrote:
>> Last time I tried this sort of stuff on Windows I seem to remember that the
>> symbol and source servers allowed me to get full stacks when running release
>> builds. Maybe this isn't currently possible on Mac? But doesn't crash reporter
>> somehow figure out full stacks for mac crash reports?
> 
> The debugger can do it, profilers generally can't because the work
> involved in correctly sampling the return addresses is much too high
> for their sampling rates.  Profilers also can't do it on Windows,
> generally.

Could they not potentially store some information and figure out this stuff
during the sample analysis after the profile run? Maybe I'm just showing my
ignorance of how things work under the hood here. :)

> You could just break in gdb and look at the stack that way, though, as
> poor man's profiling.  Given the very high proportion of CPU that's
> there, I suspect it wouldn't take too make interrupts to figure out
> what you want.

Yeah, I was hoping to avoid using gdb. Last time I did, gdb itself crashed and
took down the attached app, after which I couldn't reproduce the problem. If
there are no other options then that's what I'll do though.

>> 0.0%   0.1%   Unknown Library  0x102153000 [unknown]
>> 0.1%   0.1%   XUL                nsDisplayItem::RecomputeVisibility
>> 0.0%   0.0%   XUL                  mozilla::FrameLayerBuilder::DrawThebesLayer
>> 0.0%   0.0%   XUL                    nsRegion::SetToElements(unsigned int)
> 
> I don't remember off-hand how to tell what library is loaded at that
> address, but if symbolicating with the downloaded symbols doesn't
> work, then I'm not sure there's much you can do other than disassemble
> and poke with a debugger to see what's at that code address.

Okay. Thanks for the help.

Jonathan