Saturday, January 21, 2017

Analysis of the iOS crash report

Today, i was investigating series of the nasty crashes in iOS application. The problem really was that the application crashed on device and xcode could not fully symbolicate the crash report, hence the only thing i could see there was bunch of addresses inside the application code. Something like this:
12  CoreData                   0x195164cf8 -[NSManagedObjectContext save:] + 544
13  XXX                    0x100098c5c 0x100048000 + 330844
14  XXX                    0x10009b4c4 0x100048000 + 341188
15  XXX                    0x100072b24 0x100048000 + 174884
16  XXX                    0x1000710d8 0x100048000 + 168152
17  XXX                    0x100071810 0x100048000 + 170000
After spending half an hour digging the internet through Google i came across this discussion on StackOverflow, which gave great advise as of how to decode those addresses.

I knew that code in IDE was not changed since the tests. So, first thing i've created the new archive in XCode (Product->Archive). Once archive was created i checked its content in Finder that:

  1. Application is in place (<Archive>/Products/Applications/Name.app)
  2. Corresponding dSYM is in place (<Archive>/dSYMs/Name.app.dSYM)
Then, create a new directory somewhere and copy the above two items into the new directory. Bear in mind that both items are directories. 
Next, open crash report and note application binary module's starting address. In the above example it is 0x100048000. Then run the following command for each line you want to symbolicate:
xcrun atos -o Name.app/Name -arch arm64 -l <binary_module_start> <address>
xcrun atos -o Name.app/Name -arch arm64 -l 0x100048000 0x100098c5c
 
This command produces something like the following:
specialized Tracker.(connectToNetwork() -> ()).(closure #1) (in Name) (Model.swift:0)
Which exactly points to the line in code where error occurred.
Handy and relatively simple.

No comments:

Post a Comment