I use Fabric to log crash on my iOS App.
Today, I came across some crash related to DiskCookies. I really don't know what it means.
Crashed: diskcookies
0 CoreFoundation 0x1bd00136 CFNotificationCenterPostNotification + 53
1 libsystem_malloc.dylib 0x1b5d9cf3 szone_malloc_should_clear + 3240
2 CFNetwork 0x1c44a359 DiskCookieStorage::writeFileCompletely0(DiskCookieStorage*, FilePathStat*, MemoryCookies const*, __CFData const*, TracerData*, int) + 634
3 CFNetwork 0x1c44a49d DiskCookieStorage::_asyncWriteFileCompletely(void*) + 174
4 libdispatch.dylib 0x1b4a1783 _dispatch_client_callout + 22
5 libdispatch.dylib 0x1b4ada35 _dispatch_barrier_sync_f_invoke + 50
6 CFNetwork 0x1c44b09d DiskCookieStorage::syncStorageWithCompletionLocked(unsigned char, void () block_pointer) + 2220
7 CFNetwork 0x1c44277b ___CFHTTPCookieStorageFlushCookieStores_block_invoke + 86
8 CoreFoundation 0x1bcf5447 __CFDictionaryApplyFunction_block_invoke + 20
9 CoreFoundation 0x1bce0634 CFBasicHashApply + 120
10 CoreFoundation 0x1bce94c1 CFDictionaryApplyFunction + 152
11 CFNetwork 0x1c44270f _CFHTTPCookieStorageFlushCookieStores + 140
12 libsystem_c.dylib 0x1b53720d __cxa_finalize_ranges + 290
13 libsystem_c.dylib 0x1b4f61b3 exit + 12
14 Comico 0x97a74f UnityGetGLViewController + 4756906
15 Comico 0x97a265 UnityGetGLViewController + 4755648
16 Comico 0x980a6b UnityGetGLViewController + 4782278
17 Comico 0x96dfb5 UnityGetGLViewController + 4705808
18 Comico 0x96da59 UnityGetGLViewController + 4704436
19 Comico 0x200fe3 -[AppDelegate setUpAppGuardWithUserID:] (AppDelegate.m:1303)
20 Comico 0x1ff967 __36-[AppDelegate dologinInCallLoginAPI]_block_invoke (AppDelegate.m:1026)
21 Comico 0x13f69b __42-[NCLoginRAPIManager loginWithCompletion:]_block_invoke (NCLoginRAPIManager.m:97)
22 Comico 0xde19f -[NCRAPICompletion performBlockWithOperation:] (NCRAPICompletion.m:94)
23 CoreFoundation 0x1bd06323 -[NSArray makeObjectsPerformSelector:withObject:] + 218
24 Comico 0x3adf0d -[NCRAPIOperationRegister performCompletionBlockOfOperation:] (NCRAPIOperationRegister.m:67)
25 Comico 0x251ce1 __51-[NCRAPIManager callRAPIWithAPIRequest:completion:]_block_invoke_2 (NCRAPIManager.m:65)
26 libdispatch.dylib 0x1b4a1797 _dispatch_call_block_and_release + 10
27 libdispatch.dylib 0x1b4a1783 _dispatch_client_callout + 22
28 libdispatch.dylib 0x1b4a5d05 _dispatch_main_queue_callback_4CF + 902
29 CoreFoundation 0x1bd8fd69 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
30 CoreFoundation 0x1bd8de19 __CFRunLoopRun + 848
31 CoreFoundation 0x1bce11af CFRunLoopRunSpecific + 470
32 CoreFoundation 0x1bce0fd1 CFRunLoopRunInMode + 104
33 GraphicsServices 0x1d48bb41 GSEventRunModal + 80
34 UIKit 0x21069a53 UIApplicationMain + 150
35 Comico 0x20dc39 main (main.m:19)
36 libdyld.dylib 0x1b4ce4eb start + 2
I believe someone is trying to modify the path where network library put data to. Does anyone have any other theory or have some experience on this crash?
From the stack trace you posted here is my theory.
Frame 14 indicates that you've got a Unity application, and it's doing its thing running OpenGL.
Frame 13 is really interesting. It seems like the Unity UnityGetGLViewController (which I assume is not written by you) has called exit. This is surprising behavior, but it gives lots of clues on the rest of the stack.
Frames 12-2 look like the network stack is just doing some work on application exit (triggered by UnityGetGLViewController). Seems like it is just writing some cookie-related stuff to disk. I wouldn't worry about this.
Frame 0 and 1 are really suspect. I have a very hard time believing that malloc calls into CoreFoundation. If I had to guess, I would say that frame 0 is correct, and frame 1 has been mis-symbolicated or incorrectly unwound.
It's very unusual to call exit in iOS applications. While it is technically API, I doubt it is heavily tested. My bet is that there are some dangling pointer and/or object lifecycle issues related to the use of exit and you are seeing it here.
What I would do is see if Unity has any documentation around UnityGetGLViewController calling exit. I'd also check in with the Fabric people about frames 1 and 0. I don't see how both could be correct. And, finally, I might consider opening a bug with Apple. However, Apple usually doesn't like looking at non-Apple crash reports. So, that last one is probably a long-shot.
Related
My Xamarin project runs a simple token identification check on launch, which is where I believe it is being held up. The odd part is that it only crashes after not being opened for an extended period of time, like after 24 hours. No error is shown and the crash isn't fatal as you can still see it running in the background, but it won't launch. Once this initial error occurs, and the app is removed from the background, it launches and runs fine.
[I previously posted regarding a similar (possibly the same) issue][1], but when that occurred, it would result in a crash as well as a crash report. It stopped 'crashing' after changing the iOS linker settings.
[The code executed at launch can also be seen in a code review thread.][2]
I don't understand why this is happening, the token is definitely not expired because they are set to expire 14 days after issuing.
I'm using Azure for all backend and the web API is an ASP.NET project hosted on a free testing web hosting plan.
Crashlog:
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Region Info: 0 is not in any region. Bytes before following region: 4336173056
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 000000010274c000-0000000102794000 [ 288K] r-x/r-x SM=COW ...co.Mobile.iOS
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001be530df0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001be450948 pthread_kill + 228 (pthread.c:1458)
2 libsystem_c.dylib 0x00000001be3dfc24 __abort + 116 (abort.c:147)
3 libsystem_c.dylib 0x00000001be3dfbb0 abort + 116 (abort.c:118)
4 Ecco.Mobile.iOS 0x0000000105209d8c xamarin_initialize.cold.1 + 0
5 Ecco.Mobile.iOS 0x00000001052014a8 xamarin_printf + 44782760 (runtime.m:2468)
6 Ecco.Mobile.iOS 0x0000000105118f80 mono_invoke_unhandled_exception_hook + 43831168 (exception.c:1299)
7 Ecco.Mobile.iOS 0x00000001050ba76c mono_handle_exception_internal + 43444076 (mini-exceptions.c:2783)
8 Ecco.Mobile.iOS 0x00000001050b9154 mono_handle_exception + 43438420 (mini-exceptions.c:3107)
9 Ecco.Mobile.iOS 0x00000001050b0478 mono_arm_throw_exception + 43402360 (exceptions-arm64.c:401)
10 Ecco.Mobile.iOS 0x0000000102ba7a7c throw_exception + 172
11 Ecco.Mobile.iOS 0x00000001029180fc System_Runtime_ExceptionServices_ExceptionDispatchInfo_Throw + 44
12 Ecco.Mobile.iOS 0x000000010291f924 System_Runtime_CompilerServices_AsyncMethodBuilderCore__c__ThrowAsyncb__7_0_object + 84
13 Ecco.Mobile.iOS 0x0000000103880e3c Foundation_NSAsyncSynchronizationContextDispatcher_Apply + 18042428 (NSAction.cs:178)
14 Ecco.Mobile.iOS 0x0000000102b640f0 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
15 Ecco.Mobile.iOS 0x00000001050caab4 mono_jit_runtime_invoke + 43510452 (mini-runtime.c:3165)
16 Ecco.Mobile.iOS 0x0000000105163b9c mono_runtime_invoke_checked + 44137372 (object.c:3220)
17 Ecco.Mobile.iOS 0x0000000105167004 mono_runtime_invoke + 44150788 (object.c:3107)
18 Ecco.Mobile.iOS 0x0000000102754514 native_to_managed_trampoline_18(objc_object*, objc_selector*, _MonoMethod**, unsigned int) + 34068 (registrar.m:776)
19 Ecco.Mobile.iOS 0x0000000102755578 -[__MonoMac_NSAsyncSynchronizationContextDispatcher xamarinApplySelector] + 38264 (registrar.m:7896)
20 Foundation 0x00000001beb4ef94 __NSThreadPerformPerform + 188 (NSThread.m:807)
21 CoreFoundation 0x00000001be6c4d14 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1922)
22 CoreFoundation 0x00000001be6c4c68 __CFRunLoopDoSource0 + 84 (CFRunLoop.c:1956)
23 CoreFoundation 0x00000001be6c43c4 __CFRunLoopDoSources0 + 188 (CFRunLoop.c:1992)
24 CoreFoundation 0x00000001be6bf1fc __CFRunLoopRun + 780 (CFRunLoop.c:2882)
25 CoreFoundation 0x00000001be6bebc8 CFRunLoopRunSpecific + 480 (CFRunLoop.c:3192)
26 GraphicsServices 0x00000001c8aa05cc GSEventRunModal + 164 (GSEvent.c:2246)
27 UIKitCore 0x00000001c2871744 UIApplicationMain + 1936 (UIApplication.m:4823)
28 Ecco.Mobile.iOS 0x00000001038dfa98 wrapper_managed_to_native_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 344
29 Ecco.Mobile.iOS 0x000000010382a500 UIKit_UIApplication_Main_string___intptr_intptr + 17687808 (UIApplication.cs:86)
30 Ecco.Mobile.iOS 0x000000010382a484 UIKit_UIApplication_Main_string___string_string + 17687684 (UIApplication.cs:66)
31 Ecco.Mobile.iOS 0x0000000102796334 Ecco_Mobile_iOS_Application_Main_string__ + 303924 (/<unknown>:1)
32 Ecco.Mobile.iOS 0x0000000102b640f0 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
33 Ecco.Mobile.iOS 0x00000001050caab4 mono_jit_runtime_invoke + 43510452 (mini-runtime.c:3165)
34 Ecco.Mobile.iOS 0x0000000105163b9c mono_runtime_invoke_checked + 44137372 (object.c:3220)
35 Ecco.Mobile.iOS 0x0000000105168c94 mono_runtime_exec_main_checked + 44158100 (object.c:5284)
36 Ecco.Mobile.iOS 0x00000001050affe0 mono_jit_exec + 43401184 (driver.c:1328)
37 Ecco.Mobile.iOS 0x0000000105208238 xamarin_main + 44810808 (monotouch-main.m:0)
38 Ecco.Mobile.iOS 0x0000000102796290 main + 303760 (main.m:312)
39 libdyld.dylib 0x00000001be53b384 start + 4
Full stack trace: https://pastebin.com/VXHHdjdz
You mentioned that you're using a webapi on a free test plan. I have been using the same plan for a Project that I'm working on, and I've noticed that the first time I launch the app after extended periods of time (like the next day for example) the backend app has shut down in the meantime due to the lack of activity, and it's dependencies (like a serverless SQL instance) do too.
When the first request comes in, the API has to start up, then the SQL instance also has to start up. The two combined take long enough that the first request basically always fails spectacularly, but then the next one after works fine.
It sounds like something similar might be happening here. The Xamarin framework (also something I've been working with for a couple of years) has been... Interesting... In how it deals with some exceptions.
Anyway, I have something which may be a solution, depending on if that is the problem. Try making requests on the API just before trying to reawaken the app, and then see if it resumes properly. If it does, you might need to fiddle with your App Service settings to enable the application to be "Always On".
this was originally a comment but blasted way past the character limit so I figured it was worth a shot as an answer.
I'm deploying a build to testers via TestFlight and the app is crashing. I cannot reproduce the crash on my end so I am trying to rely on the crash logs listed in Xcode Organizer.
Unfortunately the crashes here contain some information, but nothing that allows me to identify the line of code that is causing the crash. Usually when I click on a crash in the Organizer window, it automatically shows me the line in Xcode that caused the crash.
Here's the raw crash log, which also does not contain a line number, only the file and method in which the crash occured.
Thread 0 name:
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
1 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
2 libswiftCore.dylib 0x000000010316017c 0x102f64000 + 2081148
3 libswiftCore.dylib 0x0000000103105cfc 0x102f64000 + 1711356
4 libswiftCore.dylib 0x0000000103160984 0x102f64000 + 2083204
5 libswiftCore.dylib 0x00000001030ad2f8 0x102f64000 + 1348344
6 AppName 0x0000000102c92748 specialized TableViewController.sendSmsMessage(sender:) + 8816 (TableViewController.swift:0)
(TableViewController.swift:0)
7 AppName 0x0000000102c8c448 #objc TableViewController.CorF(sender:) + 44
8 UIKitCore 0x00000001ea7a6314 -[UIApplication sendAction:to:from:forEvent:] + 96 (UIApplication.m:4786)
9 UIKitCore 0x00000001ea233d54 -[UIControl sendAction:to:forEvent:] + 80 (UIControl.m:624)
10 UIKitCore 0x00000001ea234074 -[UIControl _sendActionsForEvents:withEvent:] + 440 (UIControl.m:707)
11 UIKitCore 0x00000001ea233074 -[UIControl touchesEnded:withEvent:] + 568 (UIControl.m:461)
12 UIKitCore 0x00000001ea7dfa6c -[UIWindow _sendTouchesForEvent:] + 2472 (UIWindow.m:2204)
13 UIKitCore 0x00000001ea7e0cd0 -[UIWindow sendEvent:] + 3156 (UIWindow.m:2453)
14 UIKitCore 0x00000001ea7bffcc -[UIApplication sendEvent:] + 340 (UIApplication.m:10819)
15 UIKitCore 0x00000001ea88ee38 __dispatchPreprocessedEventFromEventQueue + 1620 (UIEventDispatcher.m:1678)
16 UIKitCore 0x00000001ea891830 __handleEventQueueInternal + 4740 (UIEventDispatcher.m:1937)
17 UIKitCore 0x00000001ea88a320 __handleHIDEventFetcherDrain + 152 (UIEventDispatcher.m:1905)
18 CoreFoundation 0x00000001bd44a0e0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 (CFRunLoop.c:1980)
19 CoreFoundation 0x00000001bd44a060 __CFRunLoopDoSource0 + 88 (CFRunLoop.c:2015)
20 CoreFoundation 0x00000001bd449944 __CFRunLoopDoSources0 + 176 (CFRunLoop.c:2051)
21 CoreFoundation 0x00000001bd444810 __CFRunLoopRun + 1040 (CFRunLoop.c:2922)
22 CoreFoundation 0x00000001bd4440e0 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
23 GraphicsServices 0x00000001bf6bd584 GSEventRunModal + 100 (GSEvent.c:2245)
24 UIKitCore 0x00000001ea7a4c00 UIApplicationMain + 212 (UIApplication.m:4347)
25 AppName 0x0000000102c7d0f0 main + 60 (SMS.swift:12)
26 libdyld.dylib 0x00000001bcf02bb4 start + 4
Any idea on how I can determine the line that is causing the crash?
EDIT: I was able to get the user to send me a crash report stored on their device as suggested by #Václav, but it doesn't seem to contain much helpful information either:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
1 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
2 libswiftCore.dylib 0x0000000104e828cc 0x104c8c000 + 2058444
3 libswiftCore.dylib 0x0000000104e28fd4 0x104c8c000 + 1691604
4 libswiftCore.dylib 0x0000000104e830cc 0x104c8c000 + 2060492
5 libswiftCore.dylib 0x0000000104dd142c 0x104c8c000 + 1332268
6 AppName 0x00000001047fa948 0x1047e0000 + 108872
7 AppName 0x00000001047f4784 0x1047e0000 + 83844
8 UIKitCore 0x00000001e6fe6314 0x1e66fc000 + 9347860
9 UIKitCore 0x00000001e6a73d54 0x1e66fc000 + 3636564
10 UIKitCore 0x00000001e6a74074 0x1e66fc000 + 3637364
11 UIKitCore 0x00000001e6a73074 0x1e66fc000 + 3633268
12 UIKitCore 0x00000001e6bfaaf0 0x1e66fc000 + 5237488
13 UIKitCore 0x00000001e6bf57ec 0x1e66fc000 + 5216236
14 UIKitCore 0x00000001e6bf52cc 0x1e66fc000 + 5214924
15 UIKitCore 0x00000001e6bf509c 0x1e66fc000 + 5214364
16 UIKitCore 0x00000001e7020cb4 0x1e66fc000 + 9587892
17 UIKitCore 0x00000001e6ffffcc 0x1e66fc000 + 9453516
18 UIKitCore 0x00000001e70cee38 0x1e66fc000 + 10300984
19 UIKitCore 0x00000001e70d1830 0x1e66fc000 + 10311728
20 UIKitCore 0x00000001e70ca320 0x1e66fc000 + 10281760
21 CoreFoundation 0x00000001b9c8a0e0 0x1b9bdd000 + 708832
22 CoreFoundation 0x00000001b9c8a060 0x1b9bdd000 + 708704
23 CoreFoundation 0x00000001b9c89944 0x1b9bdd000 + 706884
24 CoreFoundation 0x00000001b9c84810 0x1b9bdd000 + 686096
25 CoreFoundation 0x00000001b9c840e0 0x1b9bdd000 + 684256
26 GraphicsServices 0x00000001bbefd584 0x1bbef2000 + 46468
27 UIKitCore 0x00000001e6fe4c00 0x1e66fc000 + 9341952
28 AppName 0x00000001047e5860 0x1047e0000 + 22624
29 libdyld.dylib 0x00000001b9742bb4 0x1b9742000 + 2996
There are a few different elements to this question, so let me try to break it down.
Why do I see line 0?
The Swift compiler does a fair amount of code generation before actually producing a final compiled binary. In this situation, line 0 is the compiler's way of telling you that it generated code while compiling TableViewController.swift, but that code doesn't correspond to a specific line in the original source.
Because you've got a specialized function here, I'm much more inclined to believe this is compiler-generated code. This usually means the compiler is working with generic types.
I'm disappointed that Apple communicates this event in this way, but there's not much we can do. My understanding is that DWARF can describe this kind of thing. But, either Apple doesn't use this facility, it isn't written to crash reports, or most likely both.
You can verify this behavior by using atos or dwarfdump to symbolication the address 0x0000000102c92748. My bet is it will output exactly the same thing - line 0. In the past I've used dwarfdump to poke around here to see if there was more info encoded in the dSYM, but I didn't find anything. It was a few years ago though, so things might have changed.
Might a 3rd party crash reporter help?
They all use the dSYM to symbolicate, so they cannot have more information than is contained in that file. It could be worth a shot, regardless, but I doubt you'll get anywhere on the line 0 thing.
However, they probably will be able to symbolicate the frames from libswiftCore.dylib, which could be very helpful.
Why did this crash happen?
This is the million dollar question.
I'd like to see the actual crash details. My guess is it is an illegal instruction, because you've crashed inside a swift runtime library. What's likely happening is the runtime has tripped on some kind of illegal state. Unwrapping a nil Optional could definitely be it. Could also be an out of bounds Range operation. I think that out-of-bounds array indexes might also fail in this way, but off the top of my head, I'm not sure.
What I would do is just take a close look at what's going on in TableViewController.sendSmsMessage(sender:). Pay close attention to the things listed above, particularly if it is interacting with any generic standard library functions.
I would also make an attempt to symbolicate those libswiftCore.dylib frames. Again, you can use atos for this, just by pointing it at the library itself and using the load address. I'm unsure where Xcode keeps the Swift libraries internally, so you might just use the copy of the lib that was bundled with your app.
Good luck!
NOTE This is more of an iOS troubleshooting question not a React Native one. So even if you're an iOS dev and not specifically into React Native, please please read further. Your help will be greatly appreciated :)
I am building a React Native app with the Agora SDK using the react native wrapper from https://github.com/syanbo/react-native-agora
I have a weird issue when launching a new Video call, I get the following error:
2019-01-23 16:20:18.512762+0530 PwcApp[786:355367] Exception '-[AgoraRtcEngineKit setClientRole:withKey:]: unrecognized selector sent to instance 0x1072a7b80' was thrown while invoking init on target Agora with params (
{
appid = c617eddc6ceb4782adb509aa91b17580;
channelProfile = 1;
clientRole = 1;
swapWidthAndHeight = 1;
videoProfile = 40;
}
)
callstack: (
0 CoreFoundation 0x00000001beb37f10 <redacted> + 252
1 libobjc.A.dylib 0x00000001bdd05a40 objc_exception_throw + 56
2 CoreFoundation 0x00000001bea4f154 <redacted> + 0
3 CoreFoundation 0x00000001beb3d810 <redacted> + 1412
4 CoreFoundation 0x00000001beb3f4bc _CF_forwarding_prep_0 + 92
5 PwcApp 0x00000001055f48f4 -[RCTAgora init:] + 1200
6 CoreFoundation 0x00000001beb3f660 <redacted> + 144
7 CoreFoundation 0x00000001bea1b980 <redacted> + 292
8 CoreFoundation 0x00000001bea1c564 <redacted> + 60
9 PwcApp 0x00000001048fa30c -[RCTModuleMethod invokeWithBridge:module:arguments:] + 492
10 PwcApp 0x000000010493fa60 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 248
11 PwcApp 0x000000010493f7bc ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 88
12 libdispatch.dylib 0x0000000106e87840 _dispatch_call_block_and_release + 24
13 libdispatch.dylib 0x0000000106e88de4 _dispatch_client_callout + 16
14 libdispatch.dylib 0x0000000106e96a94 _dispatch_main_queue_callback_4CF + 1360
15 CoreFoundation 0x00000001beac61bc <redacted> + 12
16 CoreFoundation 0x00000001beac1084 <redacted> + 1964
17 CoreFoundation 0x00000001beac05b8 CFRunLoopRunSpecific + 436
18 GraphicsServices 0x00000001c0d34584 GSEventRunModal + 100
19 UIKitCore 0x00000001eb507558 UIApplicationMain + 212
20 PwcApp 0x0000000104787240 main + 124
21 libdyld.dylib 0x00000001be580b94 <redacted> + 4
)
This error happens only on a Release build. Debug runs completely fine. From all that I could gather this far I figured that there are a couple common culprits to this. Essentially I tried to eliminate as much difference between Release and Debug as possible. What I have tried so far:
Set Strip debug symbols on copy to NO on Release (set it same as debug).
Set Dead code stripping to NO on Release (set it same as debug).
Set Build Active Architecture only to NO on Release (set it same as debug).
Set Optimization level to NONE [-O0] (set it same as debug).
None of the above seems to solve the problem. So my question mostly now is how do I proceed in terms of troubleshooting? Is there any other setting that differs between the Debug/Release build that I could try?
In my iOS app, I keep getting crash reports like this one.
0 libsystem_kernel.dylib 0x000000018d805014 __pthread_kill + 4
1 libsystem_c.dylib 0x000000018d7799c4 abort + 136
2 libc++abi.dylib 0x000000018d2451b0 abort_message + 128
3 libc++abi.dylib 0x000000018d25ec04 default_terminate_handler() + 300
4 libobjc.A.dylib 0x000000018d26c820 objc_terminate() + 120
5 libc++abi.dylib 0x000000018d25b5d4 std::__terminate() + 12
6 libc++abi.dylib 0x000000018d25b640 std::terminate() + 56
7 libdispatch.dylib 0x000000018d6c29b4 _dispatch_client_callout + 32
8 libdispatch.dylib 0x000000018d6c75e8 _dispatch_main_queue_callback_4CF + 992
9 CoreFoundation 0x000000018e7b90c0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10 CoreFoundation 0x000000018e7b6cdc __CFRunLoopRun + 1568
11 CoreFoundation 0x000000018e6e6d94 CFRunLoopRunSpecific + 420
12 GraphicsServices 0x0000000190150074 GSEventRunModal + 96
13 UIKit 0x000000019499f44c UIApplicationMain + 204
! 14 MyAppNameHere 0x000000010007b090 main (main.m:33)
15 libdyld.dylib 0x000000018d6f559c start + 0
The strange thing is that none of this exists within my code except for the main.m. All other threads in my application don't have anything related to either. This crash appears to only happen for a fraction of a percent of my users, so I am not sure where to even start looking.
The question as it is formulated right now is not answerable, because it is missing necessary information. See e.g. this tutorial for an explanation of how to obtain a real backtrace and how to obtain a "crash reason". Without following the recommended steps for debugging crashes every crash of an iOS-app looks exactly the same as the crash you just provided.
In order to get a real/useful backtrace, you need to set an exception breakpoint in Xcode.
I have completed developing a Swift application using iOS SDK 8.1 and it is now being tested by external testers via TestFlight as beta. Recently, I have received a crash report via Crashlytics with the following stack trace:
0 libobjc.A.dylib objc_msgSend + 28 setRefreshControlState:
1 libdispatch.dylib _dispatch_call_block_and_release + 24
2 libdispatch.dylib _dispatch_client_callout + 16
3 libdispatch.dylib _dispatch_after_timer_callback + 92
4 libdispatch.dylib _dispatch_client_callout + 16
5 libdispatch.dylib _dispatch_source_latch_and_call + 792
6 libdispatch.dylib _dispatch_source_invoke + 288
7 libdispatch.dylib _dispatch_main_queue_callback_4CF + 424
8 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
9 CoreFoundation __CFRunLoopRun + 1492
10 CoreFoundation CFRunLoopRunSpecific + 396
11 GraphicsServices GSEventRunModal + 168
12 UIKit UIApplicationMain + 1488
13 opsgenie AppDelegate.swift line 0 top_level_code
14 opsgenie AppDelegate.swift line 0 main
15 libdyld.dylib start + 4
I could not replicate the issue neither on my own device, nor on simulator and this crash has happened only once in three weeks. I have no idea about what may cause this crash and what this crash report means. I have also analysed my custom Crashlytics logs which are generated, however, everything seems normal and I still have no idea about the problem. I know it is nearly impossible to understand the problem by only having this stack trace on hand, but any recommendation/idea would be very useful.
you are using pull to refresh , while the content is loading user is going to another view hence the crash.try to replicate it on a slow connection while doing pull to refresh.you can make sure you handle startRefreshing, endRefreshing methods properly