Re: Can't symbolicate crash reports
Re: Can't symbolicate crash reports
- Subject: Re: Can't symbolicate crash reports
- From: Jerry Krinock <email@hidden>
- Date: Wed, 18 Jan 2012 17:10:57 -0800
Hello António,
You didn't give your procedure. Here is my procedure. It always works (since I added step 12).
It might be kind of dated. I don't think I've used it on a 64-bit app yet. If someone wants to update it, please do!
***************************************
*** STEPS TO SYMBOLIZE A CRASH DUMP ***
***************************************
1) Move/copy both the crashing .app and the relevant.dSYM files into the same directory.
2) If the crash was in a framework, dynamic library, or bundle, you have position-independent code and must work out the *slide*. Otherwise, skip up to step 9 and use slide=0.
3) 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*.
4) Open a Terminal window
5) cd to the directory containing the crashing app and relevant .dSYM files.
6) 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
7) Note the value given for vmaddr. We call this the *Intended Load Address* and denote it as *I*.
8) Calculate the *slide* = A - I
9) 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'
10) Enter the command 'set sharedlibrary preload-libraries no'. This disables the behavior described above.
11) 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
12) Load the relevant dSYM library, for example:
add-dsym MyFramework.framework.dSYM
(Note: Usually this step is not necessary because gdb will find it in a Spotlight search under the hood. But Spotlight is only 80% reliable.
13) 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
14) If you calculated a slide, tell gdb to get info for the address minus the slide:
(gdb) info line *(<address> - <slide>)
Example:
(gdb) info line *(0x0002ef5f - 0x1000)
If gdb has an answer, it will display it like this:
Line 117 of "/Users/jk/Projects/MyApp/MyAppTableColumn.m"
starts at address 0x2ef4e <-[MyAppTableColumn dataCellForRow:]+1033>
ends at 0x2ef61 <-[MyAppTableColumn dataCellForRow:]+1052>
Repeat the preceding two steps for other interesting addresses
For further information, read this thread:
http://www.cocoabuilder.com/archive/message/xcode/2008/2/26/19750
_______________________________________________
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