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:
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
This email sent to email@hidden
