38

I have a crash report from BugSense, so I have information on the memory location of crashes but they are not symbolicated. Also Bug Sense does not send traditional crash reports but still gives me a bugtrace. So I am trying to use Atos to get the exact location of my crashes. I have archived the app in XCode 4 and used that version to submit to the app store, so I have a dSYM file. I have run the following code:

atos -arch armv7 -o MyApp.app.dSYM 0x001057e9

However, instead of getting the proper output, I am receiving an error:

atos cannot load symbols for the file MyApp.app.dSYM for architecture armv7

Any suggestions as to why this might be happening? I am not stripping debug symbols from the app.

Jason
  • 14,517
  • 25
  • 92
  • 153

2 Answers2

107

To properly get symbols from your archived app's dSYM file and get useful information from your BugSense crash reports (or any other crash reports for that matter):

  1. Copy the stack trace from BugSense into TextEdit or any other text editor. Make sure to use the "clipboard" icon, rather than simply copying the text. Otherwise you will not get the actual memory locations of the stack trace, which are necessary to look up the references using atos and symbolicate your stack trace.
  2. Open XCode and go to the Organizer
  3. Find your archive and right-click it, go to open it in the finder.
  4. Navigate to the directory of the archive, usually ~/Library/Developer/XCode/Archives/YYYY-MM-DD/
  5. Go into the specific archive, and then the dSYMs folder
  6. You will see the file MyApp.app.dSYM and you may think, this is the file that I should run atos against! This is incorrect. It is actually another package! cd into this package, into the folder: MyApp.app.dSYM/Contents/Resources/DWARF and you will find another file simply called MyApp. This is the actual dSYM file.
  7. Run atos -arch armv7 -o MyApp 0x0000000 (or whatever the memory address is) to find the location of your error, or simply atos -arch armv7 -o MyApp to enter interactive mode.
Jason
  • 14,517
  • 25
  • 92
  • 153
  • 25
    Wow, step 6 helped a lot here. Thanks! – ySgPjx Oct 19 '11 at 09:45
  • 2
    "-arch armv7" - is really important, I've got wrong data without it – AlexeyVMP Feb 27 '12 at 14:50
  • 2
    I have a backtrace but no crash log, will this still work? Seems to just give me random location. Here is an example line from my backtrace: MyApp 0x00054b23 MyApp + 301859 – jjxtra Nov 27 '12 at 15:04
  • It'll probably still work, but you won't be able to trace it up a stack tree. – Jason Nov 27 '12 at 23:50
  • This is not right. iOS 4.3 and after makes changes to the slide and load address. If you use the value from the crash file it will point to the wrong line in the code. – speeder Feb 22 '13 at 16:29
  • 1
    This answer contains help on how to calculate the correct address: http://stackoverflow.com/questions/13574933/ios-crash-reports-atos-not-working-as-expected/13576028#13576028 – Kerni Feb 22 '13 at 16:40
  • Thank you so so much, I spent more than 3 days trying to figure out how to use dSYM, step 6 really shows the exact dSYM to use. Thanks a lot – Hossam Ghareeb Jul 26 '15 at 10:00
4

You have to get the right address. You can use the solution above but you must use hex math to get the right memory address. slide + stack address - load address.

Greg Hawk
  • 41
  • 1
  • 1
    This answer shows how to get the mentioned values: http://stackoverflow.com/questions/13574933/ios-crash-reports-atos-not-working-as-expected/13576028#13576028 – Kerni Feb 22 '13 at 16:39