Re: Symbolizing Crash Dump with atos. How does it get the .dSYM?
Re: Symbolizing Crash Dump with atos. How does it get the .dSYM?
- Subject: Re: Symbolizing Crash Dump with atos. How does it get the .dSYM?
- From: Rick Altherr <email@hidden>
- Date: Mon, 25 Feb 2008 15:27:23 -0800
On Feb 25, 2008, at 2:57 PM, Jerry Krinock wrote:
On 2008 Feb, 25, at 12:19, Rick Altherr wrote:
The underlying framework that atos uses doesn't support loading
symbol names from dSYM files in Leopard.
Thank you, Rick. So I shall file a bug report on this document.
GDB does, however.
Hmmmm.... I believe I have found the method you are referring to,
described here by Jason Molenda:
http://lists.apple.com/archives/xcode-users/2006/May/msg00856.html
In order to test this out, I add the following crasher line to my
project:
id junk = (id)5 ; [junk description] ;
It is at line Migration.m line 1014, in -[Migration awakeFromNib].
Then I build and verify that a new .app and a new .dSYM are produced
in my Builds/Release:
Jerrys-Mac-Mini:Release jk$ pwd
/Users/jk/Documents/Programming/Builds/Release
Jerrys-Mac-Mini:Release jk$ ls -al
<snip></snip>
drwxrwxrwx 3 jk 501 102 Feb 25 14:10 Bookdog.app
drwxrwxrwx 3 jk 501 102 Feb 25 14:10 Bookdog.app.dSYM
<snip></snip>
Next, I run that Bookdog.app, open a Migration window, and as
expected it crashes:
Thread 0 Crashed:
0 libobjc.A.dylib 0x900fd6e4 objc_msgSend + 20
1 com.apple.AppKit 0x937dcf12 -[NSIBObjectData
nibInstantiateWithOwner:topLevelObjects:] + 1613
2 com.apple.AppKit 0x937d30ec loadNib + 264
3 com.apple.AppKit 0x937d2a4d +[NSBundle(NSNibLoading)
_loadNibFile:nameTable:withZone:ownerBundle:] + 946
4 com.apple.AppKit 0x937d2690 +[NSBundle(NSNibLoading)
loadNibFile:externalNameTable:withZone:] + 171
5 com.apple.AppKit 0x93812933 -[NSWindowController
loadWindow] + 235
6 com.apple.AppKit 0x938126cc -[NSWindowController
window] + 86
7 com.apple.AppKit 0x938125f4 -[NSWindowController
showWindow:] + 45
8 com.apple.AppKit 0x93812537 -[NSDocument showWindows] +
117
9 com.sheepsystems.Bookdog 0x0005befa 0x1000 + 372474
10 com.apple.AppKit 0x938dde56 -[NSApplication
sendAction:to:from:] + 112
11 com.apple.AppKit 0x9398c7cc -[NSMenu
performActionForItemAtIndex:] + 493
12 com.apple.AppKit 0x9398c4d1 -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:] + 220
13 com.apple.AppKit 0x9398c157 -[NSMenu
performKeyEquivalent:] + 866
14 com.apple.AppKit 0x9398a9fd -[NSApplication
_handleKeyEquivalent:] + 492
15 com.apple.AppKit 0x938a7b36 -[NSApplication sendEvent:]
+ 3838
16 com.apple.AppKit 0x938050f9 -[NSApplication run] + 847
17 com.apple.AppKit 0x937d230a NSApplicationMain + 574
18 com.sheepsystems.Bookdog 0x00002542 0x1000 + 5442
19 com.sheepsystems.Bookdog 0x00002469 0x1000 + 5225
Examining line 9 there, I expect that 0x0005befa should be my crasher.
Well, actually, it shouldn't be. The crash happened in frame 0. Now
objc_msgSend has a nasty habit of not setting up a stack frame, so the
actual originator appears to be missing. I expect that frame 9 is
actually something in your app that calls -[NSDocument showWindows].
So I create a command file like Jason did:
echo 'info line *0x5befa' > /tmp/gdbcmds
Then cd Builds/Release, and batch the command to gdb, targetting the
new executable:
gdb --batch --quiet -x /tmp/gdbcmds Bookdog.app/Contents/MacOS/Bookdog
No symbol table is loaded. Use the "file" command.
Breakpoint 1 (-[NSException raise]) pending.
No symbol table is loaded. Use the "file" command.
Breakpoint 2 (objc_exception_throw()) pending.
No symbol table is loaded. Use the "file" command.
Breakpoint 3 (-[_NSZombie release]) pending.
No symbol table is loaded. Use the "file" command.
Breakpoint 4 (szone_error) pending.
Reading symbols for shared libraries ................. done
Breakpoint 1 at 0xebd66
Pending breakpoint 1 - "-[NSException raise]" resolved
Breakpoint 4 at 0xe2626
Pending breakpoint 4 - "szone_error" resolved
Line 113 of "/Users/jk/Documents/Programming/Projects/Bookdog/
NSApplicationBookdogScripting.m" starts at address 0x5befa <-
[NSData(NSData) isEqualToData:]+10> and ends at 0x5bf05 <-
[NSData(NSData) isEqualToData:]+21>.
It does not seem to identify the crasher line that I was expecting.
What might I have done wrong?
The problem is a feature of gdb. When you tell it to look open a
file, it reads the symbol information for that file as well as the
symbol information for all the shared libraries that it directly links
against. On Leopard, nothing is prebound, so everything starts at
0x1000. Thus, your program's symbol information is read, and then
replaced by each framework it directly links against. You can avoid
this by adding a few steps:
1) Start gdb with no options. Make sure you use the correct -arch
flag if your crash report is from a different architecture.
2) Run 'set sharedlibrary preload-libraries no'. This disables the
behavior described above.
3) Load your binary with the 'file' command. In your case 'file
Bookdog.app/Contents/MacOS/Bookdog'
3) now run the 'info' command.
I tried a couple other target files; the .app itself and the .dSYM,
and got similarly wrong results...
You'll always want to specify the actual executable to gdb.
--
Rick Altherr
Architecture and Performance Group
email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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