Re: Crash Report
Re: Crash Report
- Subject: Re: Crash Report
- From: Quinn <email@hidden>
- Date: Thu, 1 Jun 2006 16:39:34 +0100
At 16:10 +0200 2/6/06, Dalton Hamilton wrote:
Does the below snippet of the Crash Report mean that the app crashed
on line 1586 of the method [MyAppIVC mountIndex:DisplayMessages:] ??
No, it means that you crashed at offset 1586 into that routine.
If you have your app's symbols handy [1], you can point GDB at it and go:
(gdb) p/a 0x000061d1
This will output the actual source line (or some approximation of it;
source level symbols just aren't reliable in optimised builds).
If you don't have a debug version of the application handy, ...
things get more complex. A good approach is to build a new version
of your app with debug symbols (or get the closest version that you
do have handy), use that to find the start of the routine in
question, and then add the offset to that address to find the
approximate crash address. Chances are, unless you've recently done
major surgery on the code, the offsets will be relatively consistent
between builds.
Alternatively, get the binary that the customer is running and
disassemble the routine in question. It's usually pretty easy to
work out the general flow of the code, and from there figure out
you're doing at that offset.
* * *
If your code is full of Objective-C, GDB's disassembly will show all
Objective-C message sends as:
0x00007a34 <-[...]+28>: call 0x2d6014 <dyld_stub_objc_msgSend>
You can work out the name of the message by looking back in the code
for the instruction that sets up 4(%esp), that is, the second
parameter to objc_msgSend. In my example, this was:
0x00007a23 <-[...]+11>: mov 0x299e60,êx
0x00007a28 <-[...]+16>: mov êx,4(%esp)
So, the memory at 0x299e60 holds the address of the SEL string for
this message. You can print this using:
(gdb) x/s *0x299e60
0x1ee294 <-[ISTPDFWindowController print:]+6848>: "osXVersion"
This allows you to track down all of the Objective-C message sends in
a particular function. Using this, you can isolate, at least
roughly, where the
crash occurred.
* * *
DTS Technote 2123 "CrashReporter" has a whole bunch of useful info
about interpreting crash logs.
<http://developer.apple.com/technotes/tn2004/tn2123.html>
[1] This has to be a version of the actual binary that you ship to
customers, but with symbols included. In general, I recommend that
you build all builds, even customer builds, with symbols, and then
strip out the symbols as part of your final packaging step.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Crash Report (From: Dalton Hamilton <email@hidden>) |