0

I have been using this technique to understand my crash report (bear with me first time doing this)

Crash Report:

Last Exception Backtrace (last 2 lines which are from my program and not a framework):

'appname' 0x0002c93e 0x2b000 + 6462

'appname' 0x0002c3f0 0x2b000 + 5104

In the terminal I type:

atos -arch armv7 -o 'appname'.app/'appname' 0x2b000 + 6462

and get back:

-[CameleonInCallNumberListViewControler callChange] (in 'appname') + 6464

+

-[CameleonAppDelegate applicationWillEnterForeground:] (in 'appname') + 546

and for the last line

atos -arch armv7 -o Caméléon.app/Caméléon 0x2b000 + 5104

and get back:

-[CameleonInCallNumberListViewControler callChange] (in 'appname') + 6464

+

-[CameleonAddressbookViewController gPressed] (in 'appname') + 88

So my question is why are there 2 selectors/method signatures showing as opposed to only one, and is there any way to get the line number it crashed on?

Community
  • 1
  • 1
owen gerig
  • 6,165
  • 6
  • 52
  • 91
  • Why are you needing to manually symbolicate the crash reports? – xyzzycoder Oct 08 '12 at 17:40
  • I have copied them into the device logs per the instructions of the answer above the linked answer. but they do not show the method calls. Im kind of guessing here as I dont know for certain, but i think I need to manually do it because of our submission protocol. We commit our build then another user compiles it and send it to apple. so i have the app.app file that was submitted but its not the same file as whats built on my computer. – owen gerig Oct 08 '12 at 17:44
  • 1
    If you want to see the line numbers, use the atos command with the dwarf file in the dSYM package that was generated alongside the application binary. There is no need to include the symbols into the app binary, it is only making the app 30-50% bigger. Symbolicating using the dSYM gives you better results because it can show you the line number too. – Kerni Oct 08 '12 at 22:46

3 Answers3

2

You are providing two numbers, so the tool is finding two methods

atos -arch armv7 -o Caméléon.app/Caméléon 0x2b000 + 5104
                                            ^1       ^2

Since these are separated, they are treated as different arguments. You should just use the first number in each line of the stack trace.

'appname' 0x0002c93e 0x2b000 + 6462
           ^

This number is the actual address of the function call. The next numbers, which you are using, are the location of the start of the method and the offset in that method. This is why the first result for each of your tests was the same. They occurred within the same method, not the same line.

ughoavgfhw
  • 39,734
  • 6
  • 101
  • 123
  • when i do that it just throws the same number back to me? why is that? – owen gerig Oct 17 '12 at 13:12
  • 1
    @owen That probably means that your application has symbols, but not debugging information, so it can only tell where functions start. It doesn't know where you are in the function, or even if you are still in the last function or in unnamed code, so it just gives you the address. Make sure the `dSym` that was created when you compiled your application is in the same folder as your application, so that `atos` can find line information from it. – ughoavgfhw Oct 17 '12 at 16:10
  • i found this answer (http://stackoverflow.com/questions/7088771/iphone-where-the-dsym-file-is-located-in-crash-report) but my .dsym was located in the /Users//Library/Developer/Xcode/DerivedData//Build/Products/Debug-iphonesimulator. I hope thats the right one. – owen gerig Oct 17 '12 at 16:30
  • @owen Probably not. The simulator uses the x86 architecture, but you are using `armv7`, which is for the device. It will probably be near the one you found, but in a folder called `Release-iphone`. If you can't find it, then you have no way of finding the line number, just the method (`-[CameleonInCallNumberListViewControler callChange]`). – ughoavgfhw Oct 17 '12 at 16:51
  • so that file would be created when you compile for a device rather then the simulator? but when you archive for app submission isnt one created then? I dont have the "release-iphone" directory because i havnt tested the app on a real device since cleaning my derived data directory. – owen gerig Oct 17 '12 at 17:03
  • The file would be created, but would not be part of the submission archive. If you removed your derived data since that build and did not save the file, the information is gone. – ughoavgfhw Oct 17 '12 at 17:06
  • no its just that the building happens on another machine. So removing my derived data shouldnt matter however like you said, the machine we do the builds on only use the simulator so that dsym file would be for x86(i guess). but ya even with that file in the same directory I still only get the address. o well, thanks for the help – owen gerig Oct 17 '12 at 18:51
  • sorry i know this is getting long. the one thing I dont understand is this: if you dont build to a device prior to submitting there is no way to symbolicate? – owen gerig Oct 17 '12 at 18:58
  • When you submit, the application will be built for the devices, so it will create the dsym file, but that file is not stored in the archive you submit, so it is still gone if you delete the derived data. – ughoavgfhw Oct 17 '12 at 19:10
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/18188/discussion-between-owen-gerig-and-ughoavgfhw) – owen gerig Oct 17 '12 at 19:57
1

Xcode has the facility for symbolicating crash reports.

If you have problems with it then take a look at posts like: Xcode 4 failure to symbolicate Crash Log

Also, there are some amazing tools out there now that make symbolicating things a lot easier like Crashlytics and Crittercism.

==== Correction

@Kerni made a good point. This is a Last Exception Backtrace so it's one thread.

==== Update

@Kerni Yes, heard good things about QuincyKit and HockeyApp too. Apologies for the omission.

Community
  • 1
  • 1
Snowcrash
  • 80,579
  • 89
  • 266
  • 376
  • but if its showing the method call (as shown above) isnt it symbolicating? meaning thats not my problem? – owen gerig Oct 08 '12 at 17:45
  • thank you, that makes sense (will mark this as answer in a bit, just want to see if anyone else offers anything) – owen gerig Oct 08 '12 at 18:14
  • This is wrong! This is not because they are called from different threads. If that would be the case, these would not show up together in the Last Exception Backtrace, but in different stack traces per thread in the crash report. – Kerni Oct 08 '12 at 22:50
  • would u use Crittercism when submitting your app? – owen gerig Oct 17 '12 at 13:23
  • You don't want me to recommend any specific implementation, since I am the developer of Quincykit and one of the Co-founders of HockeyApp.net ;) – Kerni Oct 17 '12 at 14:12
1

In extension to the answer of ughoavgfhw:

You get 3 results in that call, not two!

Your atos call actually checks 3 addresses: 0x2b000 + 6462, that's why you see 3 lines in the return! And the second time you check for these 3: 0x2b000 + 5104

You instead you should use this if you want to check against the app binary (which will not return the line number!):

atos -arch armv7 -o 'appname'.app/'appname' 0x0002c93e
atos -arch armv7 -o 'appname'.app/'appname' 0x0002c3f0

If you want to get the line numbers too, call atos and pass the dwarf file instead:

atos -arch armv7 -o 'appname'.app.dSYM/Contents/Resources/DWARF/'appname' 0x0002c93e
atos -arch armv7 -o 'appname'.app.dSYM/Contents/Resources/DWARF/'appname' 0x0002c3f0
Community
  • 1
  • 1
Kerni
  • 15,241
  • 5
  • 36
  • 57
  • where do I get the dsym info? I extract out my .app file from the .ipa file thats submitted but not sure how to access this dsym file – owen gerig Oct 17 '12 at 14:04
  • 1
    The dSYM package is usually created alongside building the app if you did not change the Xcode default build settings for that. So you can find it in the build directory where the .app is created or inside the created .xcarchive if you used the archive feature. – Kerni Oct 17 '12 at 14:13