13

I'm using Xcode 4.3.1. The crash happened on my device, so I connect it and open up Organizer, go to my device logs, find the crash report, and here's what it reads:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Last Exception Backtrace:
0   CoreFoundation                  0x3514488f __exceptionPreprocess + 163
1   libobjc.A.dylib                 0x3656b259 objc_exception_throw + 33
2   CoreFoundation                  0x35144789 +[NSException raise:format:] + 1
3   CoreFoundation                  0x351447ab +[NSException raise:format:] + 35
4   CoreFoundation                  0x350b168b -[__NSCFDictionary setObject:forKey:] + 235
5   myapp                           0x0015b4a7 0xe8000 + 472231
6   myapp                           0x0018add1 0xe8000 + 667089
7   myapp                           0x0013cd5b 0xe8000 + 347483
8   Foundation                      0x30ffb60d __NSFireTimer + 145
9   CoreFoundation                  0x35118a33 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15
10  CoreFoundation                  0x35118699 __CFRunLoopDoTimer + 365
11  CoreFoundation                  0x3511726f __CFRunLoopRun + 1207
12  CoreFoundation                  0x3509a4a5 CFRunLoopRunSpecific + 301
13  CoreFoundation                  0x3509a36d CFRunLoopRunInMode + 105
14  GraphicsServices                0x36396439 GSEventRunModal + 137
15  UIKit                           0x32190e7d UIApplicationMain + 1081
16  myapp                           0x000f6aff 0xe8000 + 60159
17  myapp                           0x000e9370 0xe8000 + 4976


Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x34f3832c __pthread_kill + 8
1   libsystem_c.dylib               0x36e34208 pthread_kill + 48
2   libsystem_c.dylib               0x36e2d298 abort + 88
3   libc++abi.dylib                 0x30af9f64 abort_message + 40
4   libc++abi.dylib                 0x30af7346 _ZL17default_terminatev + 18
5   libobjc.A.dylib                 0x3656b350 _objc_terminate + 140
6   libc++abi.dylib                 0x30af73be _ZL19safe_handler_callerPFvvE + 70
7   libc++abi.dylib                 0x30af744a std::terminate() + 14
8   libc++abi.dylib                 0x30af881e __cxa_rethrow + 82
9   libobjc.A.dylib                 0x3656b2a2 objc_exception_rethrow + 6
10  CoreFoundation                  0x3509a506 CFRunLoopRunSpecific + 398
11  CoreFoundation                  0x3509a366 CFRunLoopRunInMode + 98
12  GraphicsServices                0x36396432 GSEventRunModal + 130
13  UIKit                           0x32190e76 UIApplicationMain + 1074
14  myapp                           0x000f6af8 0xe8000 + 60152
15  myapp                           0x000e9368 0xe8000 + 4968

I thought Xcode handles symbolicating the crash reports for me automatically? Why am I not getting any line numbers or methods? And why are my exception codes 0x00000000?

I tried the method found here, but when I type in any of the memory addresses, the output is just that same memory address. Is this the most information I can get out of the crash logs, or is something wrong here?

Community
  • 1
  • 1
Snowman
  • 31,411
  • 46
  • 180
  • 303
  • Have you tried running the crash report through [atos](https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/atos.1.html)? – lottscarson May 22 '12 at 18:08
  • Yes I tried the method found in the link above, which is the atos method, but whatever memory address I type after `atos -arch armv7 -o 'myapp.app'/'myapp' MEMORY ADDRESS`, it just logs out whatever I type in for the memory address, so the output here would be MEMORY ADDRESS – Snowman May 22 '12 at 18:09
  • Another thing - the last crash happening this morning, and I changed a couple lines of code (interface stuff) and built it. I don't usually archive or anything, just build. So the crash log I have is from a previous build (though not much changed). If I don't use the archive option, could this be the reason why? – Snowman May 22 '12 at 18:18
  • Yes, that's why. Symbolicating only works for a specific build. You can't even rebuild the exact same source code. – Steven Fisher May 22 '12 at 20:52
  • I'm too having the same problem. @maq, Did you find any work-around? – Suran Jun 03 '13 at 11:01

5 Answers5

8

To symbolicate the crash report you need the dSYM package of that exact build. I guess this was a debug build that wasn't archived, so the dSYM also got overwritten the next time you build the app. This is why the organizer couldn't fully symbolicate the crash report.

The method you mentioned only works if the binary does not have symbols stripped, and even then it would not report the line numbers! So instead of using it against the app binary, rather use it with the dSYM. Maybe you are lucky and the new dSYM still has some helpful information.

atos -arch armv7 -o 'appname.app.dSYM' 0x0015b4a7

The crash itself could to be setting a NSDictionary value to e.g. a nil key.

Kerni
  • 15,241
  • 5
  • 36
  • 57
  • 2
    Fortunately with the 4.3.2 Xcode version for me the logs are symbolicated with the line numbers and w/o the current build archiving while having the `Strip Debug Symbols During Copy` set to `NO` for the Debug configurations. – A-Live May 22 '12 at 23:07
  • Then the dSYM is still available on your Mac. The symbolication script searches for it using spotlight. The symbols being part of the executable do not provide line numbers. Never. – Kerni May 23 '12 at 01:06
  • I have not been able to get this to work. My app name has a space and an apostrophe in it - I'm not sure why Apple allowed it to be submitted that way (or why I didn't think better) but I can't get to any of the debug symbols for my own code. Apple's (Core Data, UIKit, etc) come across fine. – SAHM Nov 30 '12 at 22:34
8

In the hopes that this might help someone else with the same issue, what worked for me was running the following command in the archive directory (looks like /Users/my_user/Library/Developer/Xcode/Archives/2012-09-24, so cd into there first)

mdimport .

Try running the symbolicatecrash script after that. In XCode, go to your Organizer, Device Logs, and select "Re-Symbolicate Log" by right clicking on the crash log.

Edward
  • 148
  • 2
  • 7
ruxy
  • 282
  • 3
  • 9
  • 2
    This worked perfectly for an app that I have in the market. Brilliant! What led you to find this? – paiego Dec 19 '12 at 05:31
4

I could not get XCode 4.5.1 to symbolicate by dragging the crash report into Organizer->Devices->Library->Device Logs.

Nor could I obtain the symbolicated address of the crash by specifying the dSYM per the post above by @Kerni.

I have used atos, but I could only get it to work by specifying the full path of the symbol file inside the xcarchive file (actually it's a directory). Example:

cd dir_where_the_xcarchive_is
atos -arch armv7 -o myApp\ 9-18-12\ 5.28\ PM.xcarchive/dSYMs/myApp.app.dSYM/Contents/Resources/DWARF/myApp   0x0001943a
cshavit
  • 414
  • 2
  • 12
1

Regarding your question about the Exception Codes...

Exception Codes: 0x00000000, 0x00000000

... this Apple Technical Note Might answer your question. In short, this crash report was not generated by a standard documented crash-type.

About 16 lines into the crash log, you will see a line that starts with the text followed by one or more hexadecimal values, which are processor-specific codes that may give you more information on the nature of the crash. You may tell from these codes if the application crashed due to a programming error (for example, a bad memory access, an exception, etc), or if the application was terminated for some other reason, for example:

The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. The exception code 0xbad22222 indicates that a VoIP application has been terminated by iOS because it resumed too frequently. The exception code 0xdead10cc indicates that an applicaiton has been terminated by iOS because it held on to a system resource (like the address book database) while running in the background. The exception code 0xdeadfa11 indicated that an application has been force quit by the user. Force quits occur when the user first holds down the On/Off button until "slide to power off" appears, then holds down the Home button. It's reasonable to assume that the user has done this because the application has become unresponsive, but it's not guaranteed - force quit will work on any application.

paiego
  • 3,619
  • 34
  • 43
0

Use Crashlytics instead.

It provides instant (get notified through email) about real-time crash reports, and exact line # of where a crash occurred.

bibo bode
  • 1,150
  • 1
  • 10
  • 17