5

The crashlog on iTunesConnect for my XCode 3.2.5-built application shows method names, but not line numbers. For example, in the abridged crash report I've pasted in below, it shows this:

0x000f5ef8 -[MyTableViewController dealloc] + 120

There are two things here that are puzzling me, upon which I'd appreciate some insight. The first is why the raw .crash file coming from iTunesConnect is already partially symbolized: it shows the class and method name, but not the source code file and line number. I would expect the raw iTunesConnect crashlog to show just the hexidecimal addresses. As I understand it, only once I download the crash log onto my local system and explicitly bind it using the appropriate tool (XCode Organizer, symbolicatecrash, atos, gdb x/i command, etc) and to the exact application binary and dSYM files (those having the matching UUID), will I see the full symbols of class, method, source code file, and line number. Even when I download and view the crashlog on a Windows box, it appears partially symbolized. I am concerned that my distribution binary must be including some debug symbols in order for this information to show up in the raw crashlog, despite having "Strip Linked Project" set in its Distribution target settings. Any insight here would be great.

The second thing that is perplexing me, and is of more immediate concern to me in fixing this high-profile crash, is this business of the offset. I've very carefully located the dSYM and application binary with the matching UUID, put them in my home directory so they can be found by Spotlight et al, and no matter what I do, I am unable to convert that offset [MyTableViewController dealloc] + 120 to a source code file (which is known to me to be MyTableViewController.m) and a line number. I have tried the following tricks with the raw iTunesConnect .crash file:

  • XCode Organizer: its "symbolication" affects no changes to the crashlog -- it's the same.
  • symbolicatecrash: It doesn't really complain about anything in verbose mode, and the output crashlog is the same
  • gdb: Using the same gdb and -arch setting that XCode 3.2.5 uses for producing the distribution build, and loading in the matching application binary and dSYM symbols per this post, gdb 'x/i' and 'info line *' commands tells me that [MyTableViewController dealloc] + 120 corresponds to a totally unrelated piece of our codebase in a completely different file -- a .h file, even! Wild goose chase.

Something is not right here. Even despite ensuring the exact same UUID across the crash report, the application binary, and the dSYM file ... none of these tools can yield an actual line number, and doing it the low-level way sends me on a wild goose chase. Knowing the exact line number is critical to fixing this, because we are unable to reproduce this crash in-house so we're flying blind here. This looks to be a simple over-released object, but it's not clear which exact object it is, and we're unable to tell from context. I'm wondering if there is some misappropriated XCode build setting that is somehow breaking the symbolication process.

Thanks for your time!

What follows is the abridged raw .crash log from iTunesConnect.

Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A
Hardware Model:      iPhone3,1
Process:         MyApp [1895]
Path:            /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
Identifier:      MyApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2011-01-24 14:06:32.941 -0500
OS Version:      iPhone OS 4.2.1 (8C148)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xd0000000
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x33479466 objc_msgSend + 18
1   MyApp                       0x000f5ef8 -[MyTableViewController dealloc] + 120
2   CoreFoundation                  0x33a26f74 -[NSObject(NSObject) release]
3   libobjc.A.dylib                 0x3347a812 objc_setProperty
4   UIKit                           0x320bb4a0 -[UINavigationController setDisappearingViewController:]
5   UIKit                           0x320bb478 -[UINavigationController _clearLastOperation]
xx SNIP xx
23  MyApp                       0x00014eac main + 36
24  MyApp                       0x0000b324 start + 44

XX SNIP xx

Binary Images:
    0x1000 -   0x1e3fff +MyApp armv7  <5570f8eee3bc11647732c12f96fe9553> /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
Goffredo
  • 541
  • 4
  • 14
  • 1
    As to the first question, Obj-C class/method names are embedded in the binary (as they must, for the runtime to work). This means that even without the .dSYM, a crash log can still be partially symbolicated to show the method names and instruction offsets into those methods. – Lily Ballard Feb 02 '11 at 21:37
  • The particular method you crashed on is likely just a call to `-release`, but if you want to verify, you could try following the instructions in [So you crashed in objc_msgSend()](http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html) – Lily Ballard Feb 02 '11 at 21:39
  • 2
    Have a look at this tutorial, specifically **atos**: http://www.eigo.co.uk/Deciphering-iPhone-Crash-Logs.aspx – Evan Mulawski Feb 02 '11 at 21:39
  • @Kevin: Really? There are a lot of [FAQs on the web](http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/) with people not getting class & method names in their crashreports, so I don't know that this is always true. – Goffredo Feb 03 '11 at 19:15
  • @Evan: Good lead, but it seems atos is deprecated in favor of dwarfdump. `/Xcode3.2.5/usr/bin/dwarfdump --arch armv7 --lookup=0x000f5ef8 ~/MyApp.app.dSYM` produces "not found" errors. Interestingly, looking up other addrs from this crash report (e.g., `0x00014eac`) yield expected results! I bet the addr `0x000f5ef8` is mis-reported in this crash report, causing garbage-in-garbage-out during automatic (and manual) symbolication attempts, and that's why the source file & line number don't show up. Annoying. – Goffredo Feb 03 '11 at 19:24
  • Did you ever figure out how it got partially symbolicated? I'm very curious about this as well. – Matt Hudson Jan 03 '13 at 15:49
  • @Inturbidus: No, I never figured out why this was only partially symbolicated. I've since given up with the built-in iOS crash reports in favor of a crash reporting & automatic symbolication service called HockeyApp. Despite the weird name, I can't recommend this highly enough; these guys are really dedicated. The crash logs produced by the HockeyApp system originate from open-source PLCrashReporter, and there is much more support when weird issues like this arise, than with the faceless Apple crashreports. Good luck. – Goffredo Jan 04 '13 at 19:40
  • Yeah I use TestFlight at home, but not at work. ;) – Matt Hudson Jan 04 '13 at 19:43

1 Answers1

0

I've experienced similar issues with releasing object that weren't retained or that were in an autorelease pool thereby getting released twice. More often than not I'll get a crash for a location that is inside the framework/iOS but was caused from my lack of proper memory management. I'm not saying this IS happening here, but just is something I've experienced when a similar error has presented itself.

JavaCoderEx
  • 336
  • 2
  • 9