2

I recently enabled BugSense in my App to try and help gather crash reports. I'm seeing a lot of crashes that look like they are happening immediately upon startup of my App (I haven't been able to replicate on any of my own devices). The problem is that the stack trace I'm getting from BugSense makes it look like my App actually isn't doing anything to cause the crash. All I see is the very first main call to start the AppDelegate in the trace and then a bunch of libs that don't symbolicate well.

I realize this might be not enough information to figure out my crash but perhaps I can get help with being pointed in the right direction. I can't replicate on my own devices (and several other people's devices), and the stack-trace from BugSense is from the released App out in the wild.

This is the stack trace that BugSense has given me.

libsystem_kernel.dylib              0x3089232c __pthread_kill   70444
libsystem_c.dylib                   0x37d2cfeb abort   290795
libc  abi.dylib                     0x3078ef6b abort_message   28523
libc  abi.dylib                     0x3078c34d _ZL17default_terminatev   17229
libobjc.A.dylib                     0x37d7d2e3 _objc_terminate   37603
libc  abi.dylib                     0x3078c3c5 _ZL19safe_handler_callerPFvvE   17349
libc  abi.dylib                     0x3078c451 _ZdlPv   17489
libc  abi.dylib                     0x3078d825 __cxa_current_exception_type   22565
libobjc.A.dylib                     0x37d7d235 objc_exception_rethrow   37429
CoreFoundation                      0x38187545 CFRunLoopRunSpecific   62789
CoreFoundation                      0x381873a5 CFRunLoopRunInMode   62373
GraphicsServices                    0x37f5efcd GSEventRunModal   16333
UIKit                               0x31d07743 UIApplicationMain   202563
AppNameHD                           0x000039af 0x1000   10671

I'm using instructions from, Atos cannot get symbols from dSYM of archived application , to symbolicate. It has worked for other stack traces where I actually see some of my code causing the issue just doesn't really give me any information for the above trace.

Community
  • 1
  • 1
tthmok
  • 23
  • 3
  • Hi tthmok, I'm the developer of the new version of BugSense for iOS. Are you using the latest version of the framework? What exactly is the kind of error that you get? – Nick Toumpelis Dec 07 '11 at 19:06

2 Answers2

1

Those symbolicate just fine. What they are is mangled. It probably won't help a lot , but you can unmangle them:

% c++filt -n _ZdlPv
operator delete(void*)

I don't think you get an exception from the watchdog timer, but crashing at launch makes me wonder about that, and if the crash log included BADF00D.

David Dunham
  • 8,139
  • 3
  • 28
  • 41
  • By symbolicate I meant that those memory addresses using atos don't actually show me anything except for 0x000039af which shows me the initial AppDelegate launch from main. Thanks for the tip with c++filt though. – tthmok Dec 01 '11 at 22:07
  • Everything in that crash report except 0x000039af has been symbolicated. CFRunLoopRunInMode is a symbol. __pthread_kill is a symbol. (I've seen crash reports where system symbols haven't been symbolicated, so you would know even less.) – David Dunham Dec 01 '11 at 23:47
1

That crash report won't help a lot, you need the last exception backtrace to see what parts of your code are causing the crash. As you see in the stack trace, the exception is rethrown, so happened in another runloop.

A newer version of PLCrashReporter, which BugSense crash reporting is also based on, provides that. http://code.google.com/p/plcrashreporter/

Side note: The service HockeyApp.net uses the latest version of PLCrashReporter in its open source SDK (QuincyKit.net) providing last exception backtraces and symbolication on the server. (I am a member of both)

Kerni
  • 15,241
  • 5
  • 36
  • 57