Link to download symbolicatecrash file
https://github.com/chrispix/
Syntax:
Is the address, which we want to symbolicate.
1. Using XCode:
This is probably the easiest way to symbolicate the crash reports, but not always effective.
To symbolicate using XCode you need three files:
a. Crash report (.crash file).
b. Symbol file (.dSYMB file).
c. Application bundle (.app file).
In most of the cases you will have “yourapp.ipa” file, to extract “yourapp.app“ from “yourapp.ipa” just change the extension of “yourapp.ipa” to “yourapp.zip” and extract the zip file, you will get a folder named “Payload”, in this folder you will have “yourapp.app” package.
2. Using symbolicatecrash command:
Some times XCode do not symbolicate the crash log properly, In this situation we can use symbolicatecrash script manually.
Before proceeding keep you “.app”, ”.dSYM” and “.crash” files in one folder. Now open terminal app and run following command:
Command:
1
| admin$ export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer |
This command just exports the XCode developer dir. Now run this symbolicatecrash command (It’s a command line script which is available in all MAC with Xcode installed machines).
Syntax:
Admin$ < symbolicatecrash file path> <.app file path>
Command:
1
2
| admin$ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash 'crash file path' 'app file Path'The result of execution of this command is your symbolicated crash log, which gives you information of crashing thread and cause of crash. |
3. Using atos command:
Confusion can cause many problems, if you have more than one “.ipa” and more than one “.dSYMB” and you are not sure which “.dSYMB” belongs to which “.ipa” well than this method of symbolization is for you. In this method we will find out the UUID of our files.
So before we start keep you symbol files, your app bundle and your crash reports in one folder. Now first of all we will check if the crash log belongs to the “.app” or not.
Finding UUID of dSYMB file.
- Go to the directory where we have kept all these files. (Using cd on terminal)
- Run the command:
Syntax: mdls
Command:
1
| admin$ mdls SymbolicateTest.app.dSYM |
This command list the metadata attributes for the specified file, which are:
com_apple_xcode_dsym_paths = (
“Contents/Resources/DWARF/SymbolicateTest”
)
com_apple_xcode_dsym_uuids = (
“E65307BB-B543-3D98-88FF-DC9AF42EB3CD”
)
So now you got the UUID associated with this symbol file.
Finding UUID of Crash file.
- Now we need to get the UUID of crash file, so the command is:
Syntax: grep “+” *crash
Command:
1
| admin$ grep "+SymbolicateTest" *crash |
Result:
0x8a000 – 0x8cfff +SymbolicateTest armv7s /var/mobile/Applications/71F66526-A80F-4D1C-8988-2E8D3946D91A/SymbolicateTest.app/SymbolicateTest
The structure of this result is:
The UUID is actually the most important info here.
Finding UUID of your app file
Syntax: xcrun dwarfdump –uuid
Command:
1
| admin$ xcrun dwarfdump --uuid SymbolicateTest.app/SymbolicateTest |
Result:
UUID: E65307BB-B543-3D98-88FF-DC9AF42EB3CD (armv7s) /Users/nilesh/Downloads/Symbolicate/SymbolicateTest.app/SymbolicateTest
Okay, as we can see all the UUIDs are same here it means we are good to go, and if UUIds doesn’t match stop the process here and try to get the related crash file and repeat the process again.
Now we are on the final stage, we will use atos command to symbolicate the particular image-load-address:
Syntax:
atos [-o AppName.app/AppName] [-l loadAddress] [-arch architecture]
Command:
1
| admin$ atos –o SymbolicateTest.app/SymbolicateTest -l 0x0008c366 -arch armv7s |
If your architecture is armv7s than use atos in your XCode.app
Command:
1
| admin$ /Applications/Xcode.app/Contents/Developer/usr/bin/atos –o SymbolicateTest.app/SymbolicateTest -l 0x0008c366 -arch armv7s |
Example:
SymbolicateTest -0x201E0 0x0003479e + 346494
The highlighted one is the load address.
So finally we will get the result like:
-[ViewController viewDidLoad] (in SymbolicateTest) (ViewController.m: 24)
Extras:
There might be the condition when none of your thread crashed but application exited, that could be because of system-generated exceptions and those are:
Exception codes:
In the crash log is a line that starts with the text Exception Codes: followed by one or more hexadecimal values. These are processor-specific codes that may give you more information on the nature of the crash.
• The exception code 0xbaaaaaad indicates that the log is a stackshot of the entire system, not a crash report. To take a stackshot, push the home button and any volume button. Often these logs are accidentally created by users, and do not indicate an error.
• The exception code 0xbad22222 indicates that a VoIP application has been terminated by iOS because it resumed too frequently.
• The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0: needs to be moved to a background thread, or processed differently, so that it does not block the main thread.
• The exception code 0xc00010ff indicates the app was killed by the operating system in response to a thermal event. This may be due to an issue with the particular device that this crash occurred on, or the environment it was operated in. For tips on making your app run more efficiently, see iOS Performance and Power Optimization with Instruments WWDC session.
• The exception code 0xdead10cc indicates that an application has been terminated by iOS because it held on to a system resource (like the address book database) while running in the background.
The exception code 0xdeadfa11 indicated that an application has been force quit by the user. Force quits occur when the user first holds down the On/Off button until “slide to power off” appears, then holds down the Home button. It’s reasonable to assume that the user has done this because the application has become unresponsive, but it’s not guaranteed – force quit will work on any application.Note: Terminating a suspended app by removing it from the multitasking tray does not generate a crash log. Once an app has suspended, it is eligible for termination by iOS at any time, so no crash log will be generated.
One Important note from apple:
“Important: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the “Build and Archive” command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.”
One Important note from apple:
“Important: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the “Build and Archive” command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.”
Comments
Post a Comment