Re: Haywired Call Stack in resymbolized Crash Report
Re: Haywired Call Stack in resymbolized Crash Report
- Subject: Re: Haywired Call Stack in resymbolized Crash Report
- From: Jeff Johnson <email@hidden>
- Date: Wed, 18 Nov 2009 10:07:31 -0600
Hi Jerry.
A few things to look out for:
1) Architecture mismatch. You didn't mention which architecture your
Mac has. Also, was the user running 64-bit (x86-64) or 32-bit (i386)?
If there is architecture mismatch, then gdb may not work. I tend to
use 'dwarfdump --arch= --lookup=' rather than gdb to symbolize crash
reports.
2) dSYM mismatch. The UUID for your framework in the crash report
needs to match the UUID of your dSYM, which you can determine using
'dwarfdump --uuid'.
3) Mismatch of framework load address. Your framework is almost
certainly loading at a different address of the user's machine than on
your machine (randomization). Therefore, you must take into account
the load address of the framework in the crash report when symbolizing.
Much more information is in the technical note below. In particular,
the section on position-independent code is crucial for frameworks.
http://developer.apple.com/mac/library/technotes/tn2004/tn2123.html
-Jeff
On Nov 16, 2009, at 12:23 PM, Jerry Krinock wrote:
I received a crash report from a user. The call stack for crashed
thread 0 contained 3 lines in a stripped private framework, which I
symbolized using gdb. I did this by moving the relevant app version
to a folder containing the dSYM files for the relevant version,
launching gdb, commanding 'set sharedlibrary preload-libraries no',
and then opening the appropriate binary in Contents/Frameworks/....
The crash report specifies x86 architecture and Mac OS 10.6.2. My
Mac is running 10.5.
The line numbers given by gdb 'info line' command do occur within
the given method name. However, I expect that the code given in
line N of the call stack should invoke the function/method given in
line N-1 of the call stack. But they do not.
I was wondering if anyone had ever seen gdb give a haywired call
stack like this and, if not, what else might I have done wrong?
Here is part of the call stack, with the symbol results from gdb
'info line' pasted in:
0 libobjc.A.dylib 0x96ddeedb objc_msgSend + 27
1 com.sheepsystems.Bkmxwork 0x000c5c49 0x7000 + 781385 Line
305 of Bkmslf+ActionValidator.m starts at address 0xc5c45 <-
[Bkmslf(ActionValidator) validateMenuItem:]+2140> and ends at
0xc5c4d <-[Bkmslf(ActionValidator) validateMenuItem:]+2148>.
2 com.sheepsystems.Bkmxwork 0x000c7893 0x7000 + 788627 Line
205 of StarkPredicateEditor.m starts at address 0xc7875 <-
[StarkPredicateEditor
addSimpleRowPresetToAttributeKey
:operatorType:asSubrowOfRow:targetValue:]+582> and ends at 0xc78ba <-
[StarkPredicateEditor
addSimpleRowPresetToAttributeKey
:operatorType:asSubrowOfRow:targetValue:]+651>.
3 com.sheepsystems.Bkmxwork 0x000d4054 0x7000 + 839764 Line
1730 of Bkmslf.m starts at address 0xd401e <-[Bkmslf
availableClientChoices]+351> and ends at 0xd4056 <-[Bkmslf
availableClientChoices]+407>.
4 com.apple.AppKit 0x94d170ae -[NSView
rightMouseDown:] + 68
As an example of the haywiring, look at line 3 of the call stack. I
expect that line 1730 of Bkmslf.m should be invoking the method
referenced in line 2, -[StarkPredicateEditor
addSimpleRowPresetToAttributeKey
:operatorType:asSubrowOfRow:targetValue:]. But here is the actual
code:
1728: NSMutableArray* clientChoices = [[NSMutableArray alloc] init] ;
1729: for (Client* client in clients) {
1730: [clientChoices addObject:[ClientChoice
clientChoiceWithClient:client]] ;
1731: }
As you can see, it's not even close.
Big thanks to anyone who could offer a guess as to what might have
gone wrong.
Jerry Krinock
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden