I'm working on an iOS app that uses Realm which is installed/managed via Cocoapods. My app crashes sporadically and I'm having difficulty troubleshooting the problem because my stack trace doesn't show me the method names related to Realm. I am deploying a debug build of my app to the phone via Xcode and I have the Debug Information Format option set to DWARF with dSYM File. In the stack trace below you can see that my code appears to be symbolicated but the method names in Realm are just addresses and offsets. Unfortunately, I'm somewhat new to troubleshooting with Xcode but I'm under the assumption that this means the Realm debug symbols could not be found? If anyone can explain to me how to correct this, I'd really appreciate it!
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x18316ad8c __exceptionPreprocess + 228
1 libobjc.A.dylib 0x1823245ec objc_exception_throw + 55
2 Realm 0x10814e238 0x108030000 + 1172024
3 Realm 0x10814ffa0 0x108030000 + 1179552
4 Realm 0x10814ff74 0x108030000 + 1179508
5 MyAppName 0x104af31a4 closure #1 in closure #2 in processOutgoingMessage(outgoingMessage:) + 4452772 (ProcessOutgoingMessage.swift:51)
6 MyAppName 0x1046cd168 _T0Ieg_IeyB_TR + 102760 (DataSource.swift:0)
7 libdispatch.dylib 0x182a5caa0 _dispatch_call_block_and_release + 23
8 libdispatch.dylib 0x182a5ca60 _dispatch_client_callout + 15
9 libdispatch.dylib 0x182a9dd80 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 963
10 CoreFoundation 0x183113070 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 11
11 CoreFoundation 0x183110bc8 __CFRunLoopRun + 2271
12 CoreFoundation 0x183030da8 CFRunLoopRunSpecific + 551
13 GraphicsServices 0x185015020 GSEventRunModal + 99
14 UIKit 0x18d04d758 UIApplicationMain + 235
15 MyAppName 0x104a7919c main + 3953052 (AppDelegate.swift:18)
16 libdyld.dylib 0x182ac1fc0 start + 3
UPDATE - as it turns out, the Build Settings for the Pods project (recall that I'm using Realm via Cocoapods) needed to also have the Debug Information Format set to DWARF with dSYM File for debug builds. My app hasn't crashed again yet but I did notice that when I cleaned and rebuilt the app this time it appeared to be including the debug symbols for Realm so here's hoping.
Related
We've had a few very bizarre crashes in our app recently. They are not reliably reproducable. The crashes have all occurred on iOS 11 devices so far. Our app is written in Swift 3.2. We are using Xcode 9.0.1 with the standard build system (not the new Swift build system). It seems that after performing a certain web request, the app crashes with the below stack trace:
Crashed: com.apple.main-thread
0 OurFramework 0x105283e84 __swift_deallocate_boxed_opaque_existential_0 + 2588
1 OurFramework 0x10528366c __swift_deallocate_boxed_opaque_existential_0 + 516
2 OurFramework 0x10528b368 swift_rt_swift_storeEnumTagSinglePayload + 24748
3 OurFramework 0x1052911cc swift_rt_swift_storeEnumTagSinglePayload + 48912
4 OurFramework 0x1052133d8 __swift_memmove_array32_8 + 1336
5 OurFramework 0x10521304c __swift_memmove_array32_8 + 428
6 OurFramework 0x105292504 swift_rt_swift_storeEnumTagSinglePayload + 53832
7 Alamofire 0x1057cac64 _T09Alamofire11DataRequestC8responseACXDSo13DispatchQueueCSg5queue_x0D10SerializeryAA0B8ResponseVy16SerializedObjectQzGc17completionHandlertAA0biH8ProtocolRzlFyycfU_yycfU_AA0biH0VyypG_Tg5 + 264
8 Alamofire 0x1057ca3f8 _T0Ix_IyB_TR + 36
9 libdispatch.dylib 0x1860c5088 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1860c5048 _dispatch_client_callout + 16
11 libdispatch.dylib 0x1860d1b74 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1016
12 CoreFoundation 0x1866e9eb0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation 0x1866e7a8c __CFRunLoopRun + 2012
14 CoreFoundation 0x186607fb8 CFRunLoopRunSpecific + 436
15 GraphicsServices 0x18849ff84 GSEventRunModal + 100
16 UIKit 0x18fbdc2e8 UIApplicationMain + 208
17 OurApp 0x104de98b0 main (main.swift:19)
18 libdyld.dylib 0x18612a56c start + 4
We are using Crashlytics to track our crashes and I'm not sure if it's because of a symbolication issue that I don't see more info than this but the trace indicates that something is going awry during a web request. Our app uses Alamofire to make web requests. Results from our testing where this crash occurred also support this theory since the crashes always occurred right after the app made a request to our backend. Could it be that in iOS 11 something changed in the underlying NSURLSession that Alamofire uses? Maybe iOS 11 is using a different caching strategy or something that's causing alamofire to invoke our result completion handler in a way that causes this crash? Has anyone seen this kind of crash before? What do __swift_deallocate_boxed_opaque_existential and swift_rt_swift_storeEnumTagSinglePayload mean? Any help is greatly appreciated, thank you!
Finally I finish my application so it is time to make some beta test. So I upload my application to itunes connect to test it out with test flight, but it keep crashing when I perform few task.
When I try to open the app from downloaded menu in test flight app.
When I try make a http request with AFnetworking
When I insert new record to CoreData
Sometime when i open the app from test flight it did not crash but show me a black screen after lauch screen.
I have been searching for 5 day without any clue. I been test it out with both release and debug mode running from xcode it doesn't crash at all. The problem only occur on if the app install from testflight. I think might be some memory allocated issues. It is a bug from testflight? How can I make the same behaviour happening at test flight happen in my xcode as well to know and fix the error.
I'm targeting ios 8.0 ++
Testing on iphone 7 plus(ios 10.2) and iphone 5s(ios 9.3).
Xcode 8.3.2
I get alot of difference crash report but most of it similiar to this one. Maybe I insert some nil value into dictionary? But why does it not happen when I build it from xcode.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x18319ee38 __exceptionPreprocess + 124
1 libobjc.A.dylib 0x182803f80 objc_exception_throw + 56
2 CoreFoundation 0x183084554 -[__NSDictionaryM setObject:forKey:] + 924
3 Cellecter 0x1001db19c 0x100040000 + 1683868
4 Cellecter 0x1001dafe4 0x100040000 + 1683428
5 CoreFoundation 0x183140eac __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
6 CoreFoundation 0x1831406cc _CFXRegistrationPost + 396
7 CoreFoundation 0x18314044c ___CFXNotificationPost_block_invoke + 60
8 CoreFoundation 0x1831a9494 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1532
9 CoreFoundation 0x18307e788 _CFXNotificationPost + 368
10 Foundation 0x183adfd1c postQueueNotifications + 684
11 CoreFoundation 0x1831547b0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
12 CoreFoundation 0x183152554 __CFRunLoopDoObservers + 372
13 CoreFoundation 0x183152884 __CFRunLoopRun + 672
14 CoreFoundation 0x18307cd10 CFRunLoopRunSpecific + 384
15 GraphicsServices 0x184964088 GSEventRunModal + 180
16 UIKit 0x188351f70 UIApplicationMain + 204
17 Cellecter 0x1001e8834 0x100040000 + 1738804
18 libdyld.dylib 0x182c1a8b8 start + 4
Updated: some how the my first and fourth question have been fix Now my question narrow it down to crashing when try to insert record into afnetworking.
This could be a lot of things.
It can be a migration issue with CoreData, a ManagedObjectContext issue.
The blackscreen could be a view issue.
Your question is too broad, we don't have code, we don't know your recent development.
Are you using real devices ? Emulators ? Which version of Xcode ? iOS deployment target ?
Please refer to this post next time you ask a question.
How to Ask
I finally manage to fix the issues. Actually the issues is quite simple, I will not be able to fix the issues if I don't symbolicate my crash report, actually the issues is on FCM, From here specifically say I need a production push certificate in order to receive the device token. Which the device token return nil every time and I attempt save the token to core data.
I am wondering if there is anything in the following stack trace that I received from Crashlytics that I should be concerned about:
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x000000007becbeb8
Thread : Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x3a3c61fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3a42fa33 pthread_kill + 58
2 libsystem_c.dylib 0x3a376ffd abort + 76
3 libc++abi.dylib 0x396a5cd7 abort_message + 74
4 libc++abi.dylib 0x396be6e5 default_terminate_handler() + 252
5 libobjc.A.dylib 0x39e07921 _objc_terminate() + 192
6 libc++abi.dylib 0x396bc1c7 std::__terminate(void (*)()) + 78
7 libc++abi.dylib 0x396bbd2d __cxa_increment_exception_refcount
8 libobjc.A.dylib 0x39e077f7 objc_exception_rethrow + 42
9 CoreFoundation 0x2f499c9d CFRunLoopRunSpecific + 640
10 CoreFoundation 0x2f499a0b CFRunLoopRunInMode + 106
11 GraphicsServices 0x3419a283 GSEventRunModal + 138
12 UIKit 0x31d3d049 UIApplicationMain + 1136
13 Pocket Linesman 0x0005aa8b main + 17 (main.m:17)
From my searching around the internet, I am unable to find an example of where this type of crash has an actionable fix for it. Also, I am completely unable to reproduce a crash like this through a normal interaction in my app.
Does this stack trace indicate a normal crash due to low memory issues on the user's iOS device, or something more?
This is my first app using Crashlytics, so i am still learning how to read the reports it sends me.
Thanks!
The original source of the crash is an uncaught exception. The original exception was caught and rethrown from CFRunLoopRunSpecific(). That has obscured the original source of the exception in the backtrace. Sometimes, the exception details are logged and they might indicate the original backtrace. Do you have any log messages that may have been written at the same time?
I was running into the same issue whenever the crash was caused by UI code.
Have you set NSSetUncaughtExceptionHandler in your app delegate by any chance? Setting mine caused me to get the useless pthread_kill message.
Unsetting mine in distributed builds allowed me to get more useful crash reporting from the same error.
Hope this helps :)
I've received crash report on my submitted iOS app from apple, which is:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 APPNAME 0x00071fc8 0x6d000 + 20424
1 APPNAME 0x000733ce 0x6d000 + 25550
2 APPNAME 0x00072cc0 0x6d000 + 23744
3 Foundation 0x354cd2ee 0x354bb000 + 74478
.....
14 CoreFoundation 0x3707bebc 0x37073000 + 36540
15 CoreFoundation 0x3707bdc4 0x37073000 + 36292
GraphicsServices 0x36835418 0x36831000 + 17432
17 GraphicsServices 0x368354c4 0x36831000 + 17604
18 UIKit 0x35f25d62 0x35ef7000 + 191842
19 UIKit 0x35f23800 0x35ef7000 + 182272
20 APPNAME 0x0006ed46 0x6d000 + 7494
21 APPNAME 0x0006ed10 0x6d000 + 7440
I've also been looking at atos command and dwarfdump. I have both .dsym and the .app that was submitted to apple. However, I couldn't find a thing using the memory address given by apple (ex. 0x0006ed46, 0x00071fc8, etc. ). I tried randomizing address and found that my application address is actually between 0x0002xxx to 0x0007xxx
What happened? How can I know which part of my application causes the bug?
Best Regards,
You need to symbolicate your crash report using the dsym file. You can see the answer here:
Symbolicating iPhone App Crash Reports
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/