2

The following is the thread that causes my app to crash when it resumes from idle. I tried plugging in my iPhone, going to organizer, clicking on the iPhone, and going to device logs. But when I click Re-Symbolicate, nothing happens. Please advise and provide detailed directions to symbolicate so I can find the cause of the crash. I tried looking up how to symbolicate but I was unsuccessful.

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x3b8fa350 __pthread_kill + 8
1   libsystem_c.dylib               0x3b87111e pthread_kill + 54
2   libsystem_c.dylib               0x3b8ad96e abort + 90
3   libc++abi.dylib                 0x3ae4bd4a abort_message + 70
4   libc++abi.dylib                 0x3ae48ff4 default_terminate() + 20
5   libobjc.A.dylib                 0x3b3fca74 _objc_terminate() + 144
6   libc++abi.dylib                 0x3ae49078 safe_handler_caller(void (*)()) + 76
7   libc++abi.dylib                 0x3ae49110 std::terminate() + 16
8   libc++abi.dylib                 0x3ae4a594 __cxa_rethrow + 84
9   libobjc.A.dylib                 0x3b3fc9cc objc_exception_rethrow + 8
10  CoreFoundation                  0x3369df1c CFRunLoopRunSpecific + 452
11  CoreFoundation                  0x3369dd44 CFRunLoopRunInMode + 100
12  GraphicsServices                0x372612e6 GSEventRunModal + 70
13  UIKit                           0x355b32fc UIApplicationMain + 1116
14  FitGoal                         0x00080cc0 0x7a000 + 27840
15  libdyld.dylib                   0x3b833b1c tlv_initializer + 4

2 Answers2

2
  1. Symbolication doesn't work because the dSYM and app binary that caused the crash cannot be found using Spotlight or either of the two files is missing.

  2. Symbolication would only reveal that frame #14 is a call to main.m, which doesn't help you.

  3. The crash is caused by an exception. To find the cause of the crash you would need to have the Application Specific Information block in the report that tells you which exception was raised, and also the Last Exception Backtrace which would show you where the exception happened in the code. Both parts are usually missing in iOS crash reports from Apple.

To find the cause of the crash you have to:

  1. Add an exception breakpoint.
  2. Start the app with the debugger in Xcode running (Menu Product - Run)
  3. Reproduce the scenario that triggered the crash.
Community
  • 1
  • 1
Kerni
  • 15,241
  • 5
  • 36
  • 57
  • Kemi is correct, those are the situations you're dealing with for this particular crash. That being said, you should always generate debug DWARF symbols with each build if you can manage it as this will allow post release symbolication. However, I don't agree that symbolicating won't necessarily help in this case. – pixelknitter Jun 01 '14 at 17:47
  • @EddieFreeman: how can symbolication help with this crash report? frame #14 will show `main.m` and nothing else. It would help if there would be a `Last Exception Backtrace`, but since that doesn't exist, it will not help here. (Those exception backtraces are usually missing in iOS crash reports) – Kerni Jun 01 '14 at 19:35
  • It would show the framework method path (not line numbers, but knowing what methods are being called is helpful) assuming the symbols are packaged. That being said, you will have to place some log statements to capture where your app is crashing or take the breakpoint approach. – pixelknitter Jun 10 '14 at 05:52
  • This is only true if symbols are not stripped from the binary. But stripping symbols from the binaries is default setting in release mode and recommended, since it saves (a lot of) space. – Kerni Jun 10 '14 at 08:32
0

I think that you have tested in Release mode. In that mode, the default value of "Strip Debug Symbols During Copy" is YES.

If this option is enable (YES), you must have the .dsym file in order to symbolicate, other wise, you have to disable it (NO).

Search google about "Strip Debug Symbols During Copy".

enter image description here

Duyen-Hoa
  • 15,384
  • 5
  • 35
  • 44