Re: Resolving a crash address to position in code
Re: Resolving a crash address to position in code
- Subject: Re: Resolving a crash address to position in code
- From: Jerry Krinock <email@hidden>
- Date: Mon, 18 Apr 2011 18:29:11 -0700
On 2011 Apr 18, at 13:36, Peter Hudson wrote:
> I've hunted around on the web for material on using dwarfdump - but can't find anything much.
> Any suggestions appreciated !
Here is my "cheat sheet" for symbolizing crash dumps. Fortunately, I don't need to use it often enough to remember it :)
***************************************
*** STEPS TO SYMBOLIZE A CRASH DUMP ***
***************************************
On 2009 Nov 18, at 08:07, in xcode-users, Jeff Johnson wrote:
Watch for 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.
That being said, here's the way that I know...
* Move/copy both the crashing .app and the relevant.dSYM files into the same directory.
IF THE CRASH WAS IN A FRAMEWORK, DYNAMIC LIBRARY OR BUNDLE
You have position-independent code and must work out the *slide*.
* Look in the *Binary Images* part of the crash log and find the framework, dynamic libray or bundle in which the crash occurred. Read the first column of the output. This is the address at which the __TEXT segment was loaded. We call it the *Actual Load Address* and denote it as *A*.
* Open a Terminal window
* cd to the directory containing the crashing app and relevant .dSYM files.
* Run the following command:
otool -l MyApp.app/Contents/Frameworks/MyFramework.framework/MyFramework | grep -B 3 -A 8 -m 1 "__TEXT"
You will get output which looks like this:
Load command 0
cmd LC_SEGMENT
cmdsize 464
segname __TEXT
vmaddr 0x00000000
vmsize 0x00111000
fileoff 0
filesize 1118208
maxprot 0x00000007
initprot 0x00000005
nsects 6
flags 0x0
* Note the value given for vmaddr. We call this the *Intended Load Address* and denote it as *I*.
* Calculate the *slide* = A - I
* By the way, it seems that Crash Reporter now calculates the slide for you. For example, in this line:
1 com.mycompany.MyFramework 0x000c5c49 0x7000 + 781385
After going through the procedure of calculating the slide using otool as explained in TN2123, it turned out to be 0x7000. Does anyone know if this is a new feature of Crash Reporter that is not yet documented in TN2123?
1) Open a Terminal window and 'cd' to this directory.
2) Enter "gdb" with no options, unless your crash report is from a different architecture. Then, you must make sure you use the correct -arch flag. Example, if the crash occurred on a PowerPC and you are not running now on a PowerPC: 'gdb -arch ppc'. If the crash occurred when running a 32-bit app on an Intel Mac and you are running on a 64-bit Intel Mac: 'gdb -arch i386'
3) Enter the command 'set sharedlibrary preload-libraries no'. This disables the behavior described above.
4) Load your binary with the 'file' command.
Example for main executable:
file MyApp.app/Contents/MacOS/MyApp
Example for framework (note that it's OK to use the symlink in the framework)
file MyApp.app/Contents/Frameworks/MyFramework.framework/MyFramework
5) Look at the crash report and find the first interesting address in the call stack. For example, in
12 com.mycompany.MyApp 0x0002ef5f 0x1000 + 254908
the address is 0x0002ef5f
6) If you calculated a slide, tell gdb to calculate the slid address:
(gdb) p/x <address>-<slide>
For example
(gdb) p/x 0x10005f2e-0x7000
gdb will assign the result to a built-in variable
$1 = 0xfffef2e
Now get the answer by
(gdb) info line *$1
If you did not calculate a slide, ask for it directly
(gdb) info line *<address>
For example,
(gdb) info line *0x0002ef5f
In either case, if gdb has an answer, it will display it like this:
Line 117 of "/Users/jk/Documents/Projects/MyApp/MyAppTableColumn.m"
starts at address 0x2ef4e <-[MyAppTableColumn dataCellForRow:]+1033>
ends at 0x2ef61 <-[MyAppTableColumn dataCellForRow:]+1052>
For further information, read this thread:
http://www.cocoabuilder.com/archive/message/xcode/2008/2/26/19750
*******************************************************
*** STEPS TO GET GRANULARITY TO LINE NUMBER -- EEK! ***
*******************************************************
As you can see, the following is a real pain. Usually, after you've isolated the crash to a method, your time will be better spent examining the method's code and thinking "what if" at each line. But if you *must* put yourself through the torture of translating the offset to a line number, first of all, slap yourself on the face for writing such long methods. Then, here you go:
On Dec 2, 2009, at 4:55 PM, Graham Cox wrote:
> When I get a stack trace in a crash report, as exampled below, can I use the offsets (+71, +50) to locate the relevant line in the source code? What do these numbers actually mean?
>
> 1 com.apptree.drawkit 0x001c7bb9 -[DKDrawableObject encodeWithCoder:] + 71
> 2 com.mapdiva.ortelius 0x0003c81d -[DKOSymbol encodeWithCoder:] + 50
This reply from Greg Parker of Apple, "Runtime Wrangler"
That's the offset in bytes of the CPU instruction in that function - the crashing instruction in the top frame, and the instruction after the call in the other frames.
You can recover the line number if you have the binary and dSYM file that match the version from the crash.
(The values below are all fake.)
1. Find the binary's UUID in the Binary Images section of the crash log.
Binary Images:
0x1000 - 0x1ff7 +com.apptree.drawkit ??? (???) <A84E261F-B98E-8ECD-3A40-24C65353BE3E> /path/to/DrawKit.framework/Contents/MacOS/DrawKit
2. Find the binary for the version with that UUID.
% dwarfdump -u /path/to/DrawKit.framework
UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework/Contents/MacOS/DrawKit
UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework/Contents/MacOS/DrawKit
3. Find the dSYM file with that UUID. A Spotlight search for the UUID may work.
% dwarfdump -u /path/to/DrawKit.framework.dSYM
UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit
UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit
4. Run gdb with that architecture, binary, and dSYM.
% gdb -arch i386 /path/to/DrawKit.framework
(gdb) add-dsym /path/to/DrawKit.framework.dSYM
5. Ask gdb for the line number for that function+offset. (Note the actual address may not match the one in the crash log.)
(gdb) x/i '-[DKDrawableObject encodeWithCoder:]' + 71
0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> ...
(gdb) info line *0x4bb9
Line 55 of "DKDrawableObject.m" starts at address 0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> and ends at 0x4bc9 <-[DKDrawableObject encodeWithCoder:]+87>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden