IOS app crash, symbolized logs are opaque
I believe I am looking at logs correctly symbolized, but please tell me if this is not the case. This is an excerpt from the crash log that I received from Apple after being rejected due to a crash on startup that I was unable to fully reproduce.
I installed a crash reporting system called Crashlytics which was getting no crash reports for the time the app was in overview, which led me to crash before AppDelegate didFinishLaunchingWithOptions
where Crashlytics is initialized. However, Crashlytics only sends reports after reopening the app after a crash. So the Apple reviewer may have crashed and didn't try again, perhaps the reason I don't have a Crashlytics report.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Last Exception Backtrace:
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08)
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000193172964 __kill + 8
1 Luff 0x00000001001330dc 0x10005c000 + 880860
2 libsystem_platform.dylib 0x0000000193208958 _sigtramp + 64
3 libsystem_pthread.dylib 0x0000000193211224 pthread_kill + 108
4 libsystem_c.dylib 0x00000001930eab14 abort + 108
5 libc++abi.dylib 0x00000001921d1414 abort_message + 112
6 libc++abi.dylib 0x00000001921f0b88 default_terminate_handler() + 300
7 libobjc.A.dylib 0x00000001929ec3bc _objc_terminate() + 124
8 libc++abi.dylib 0x00000001921edbb0 std::__terminate(void (*)()) + 12
9 libc++abi.dylib 0x00000001921ed738 __cxa_rethrow + 140
10 libobjc.A.dylib 0x00000001929ec290 objc_exception_rethrow + 40
11 CoreFoundation 0x0000000181e7d710 CFRunLoopRunSpecific + 568
12 UIKit 0x0000000186787988 -[UIApplication _run] + 548
13 UIKit 0x0000000186782980 UIApplicationMain + 1484
14 Luff 0x0000000100061c24 0x10005c000 + 23588
15 libdyld.dylib 0x000000019305aa04 start + 0
source to share
What you have is NOT fully symbolized. To get it completely symbolically, i.e. With your function names on lines 14 and 1 and the last back-blind exception, you need a dSYM file that would be generated when you create your app for and placed in the same folder as your app bundle. If you've used the Xcode archive functionality, I believe dSYM is included in the archive. I say lines 1 and 14 because the ones that have your application name on them (Luff).
What you need to do is put the crash report, dSYM file, and application file (not IPA) in the same folder (I'm not sure if the application file is really needed for the Xcode symbol, so make sure it is there if it is does not work only with error message and dSYM). Then import the crash report into Xcode organizer and click Re-symbolize.
What you have above, as now, is 100% useless without dSYM, if you cannot somehow match addresses in the report with symbols (functions, methods).
Also, the split thread stack trace is not where the relevant information is . From experience I can tell you a couple of things about this stack trace. The character on line 14 is most likely your main () function. Nothing special.
Lines between 1 and 14 show a bunch of exception and exception catch, i.e. it is not the stack trace that caused the crash, but the stack exception is thrown. Since you mentioned that you have Crashlytics, I bet line 14 is just that. He says Luff, not Crashlytics, because Crashlytics is a static library built into your application. For all intents and purposes, iOS treats this as just another part of your application. The reason I say is Crashlytics, when you crash crashes, what caused the crash (exception, signal, etc.) sometimes recovers and eventually reaches your own crash code.
the relevant information is in the addresses Last Exception Backtrace
you have provided above. But to read this, it must be symbolized by the dSYM file.
As you said, Crashlytics is not real-time. The user must open the app again. I know all this because I am working on my own project Crashional , which is in real time , provided there is an internet connection.
source to share