We have a crash in our iOS app reported by Crashlytics:
Device: iPhone 6+
iOS: 10.0.1
The stack trace is:
Crashed: XPC API Misuse: Over-resume of a connection.
0 libxpc.dylib 0x18eb526b0 _xpc_api_misuse + 48
1 libxpc.dylib 0x18eb526b0 _xpc_api_misuse + 48
2 libxpc.dylib 0x18eb3ec08 xpc_connection_resume + 76
3 CFNetwork 0x190138500 -[__NSURLBackgroundSession setupXPCConnection] + 292
4 CFNetwork 0x190139260 -[__NSURLBackgroundSession ensureRemoteSession] + 64
5 libdispatch.dylib 0x18e8f5200 _dispatch_call_block_and_release + 24
6 libdispatch.dylib 0x18e8f51c0 _dispatch_client_callout + 16
7 libdispatch.dylib 0x18e903444 _dispatch_queue_serial_drain + 928
8 libdispatch.dylib 0x18e8f89a8 _dispatch_queue_invoke + 652
9 libdispatch.dylib 0x18e903940 _dispatch_queue_override_invoke + 360
10 libdispatch.dylib 0x18e90538c _dispatch_root_queue_drain + 572
11 libdispatch.dylib 0x18e9050ec _dispatch_worker_thread3 + 124
12 libsystem_pthread.dylib 0x18eafd2c8 _pthread_wqthread + 1288
13 libsystem_pthread.dylib 0x18eafcdb4 start_wqthread + 4
Any idea about how to reproduce it?
Any idea about what can create the crash?
Crashlytics Insights
Heads Up!
XPC API Misuse by a NSURLSession
Details:
The stack trace indicates an issue with usage of the XPC API. It looks like NSURLSession background uploads is causing issues with XPC. Since XPC is not available to third-party developers on iOS, this is probably an Apple bug. If this affects your ability to use background uploads, we recommend filing a radar with Apple and working around background uploads, if possible.
Resources:
Apple Developer Forums: XPC API Misuse - iOS 9 crash
Answers Changelog, version 1.3.3
Related
I've got an error in my app (iOS 8 to iOS 11) :
Crashed: com.apple.root.default-qos
0 libsystem_kernel.dylib 0x1839a00a8 __abort_with_payload + 8
1 libsystem_kernel.dylib 0x18399b100 abort_with_payload_wrapper_internal + 100
2 libsystem_kernel.dylib 0x18399b12c system_set_sfi_window + 10
3 TCC 0x1868ed99c __TCCAccessRequest_block_invoke_2.85 + 222
4 TCC 0x1868ed8bc __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 706
5 TCC 0x1868f113c __tccd_send_block_invoke + 316
6 libxpc.dylib 0x183aeda0c _xpc_connection_reply_callout + 60
7 libxpc.dylib 0x183aed948 _xpc_connection_call_reply_async + 88
8 libdispatch.dylib 0x18380d758 _dispatch_client_callout3 + 16
9 libdispatch.dylib 0x183825060 _dispatch_mach_msg_async_reply_invoke$VARIANT$mp + 324
10 libdispatch.dylib 0x183813f54 _dispatch_queue_override_invoke$VARIANT$mp + 400
11 libdispatch.dylib 0x18381a1c8 _dispatch_root_queue_drain + 596
12 libdispatch.dylib 0x183819f10 _dispatch_worker_thread3 + 120
13 libsystem_pthread.dylib 0x183ab3130 _pthread_wqthread + 1268
14 libsystem_pthread.dylib 0x183ab2c30 start_wqthread + 4
I've read some subjects about errors like this one. Each time, people says that comes from Permissions in infos.plist.
App uses camera, library, geolocation. So I add :
Privacy - Camera Usage Description
Privacy - Location When in Use
Privacy - Photo Library Usage Description
But there is always the same problem.
I add Microphone usage in plist, but same crash occurs.
I don't understand the crash. On my iPhone, everything works perfectly but on some devices, this error cause crashes. Could you help me please ?
Thanks.
Check all of your WKWebView that is are loading images.
If you long press on Webview it shows an option to save photos in app.
Fix for the crash:
webView?.allowsLinkPreview = false
I am having the following crash (0.05% crash rate, so I have yet to reproduce it):
0 libdispatch.dylib 0x208b2028 _dispatch_semaphore_signal_slow + 174
! 1 MyProject 0x00253f39 __64-[CRNSURLSessionTaskProxy wrapDataCompletionHandler:forSession:]_block_invoke + 422
2 CFNetwork 0x2120796d __75-[__NSURLSessionLocal taskForClass:request:uploadFile:bodyData:completion:]_block_invoke + 14
3 CFNetwork 0x21216ef7 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 276
4 Foundation 0x2150a52d __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 6
5 Foundation 0x2146beff -[NSBlockOperation main] + 144
6 Foundation 0x2145e2ef -[__NSOperationInternal _start:] + 772
7 Foundation 0x2150c7ed __NSOQSchedule_f + 190
8 libdispatch.dylib 0x208adf97 _dispatch_queue_drain + 1760
9 libdispatch.dylib 0x208a6f2f _dispatch_queue_invoke + 280
10 libdispatch.dylib 0x208af325 _dispatch_root_queue_drain + 398
11 libdispatch.dylib 0x208af193 _dispatch_worker_thread3 + 92
12 libsystem_pthread.dylib 0x20a3ce0d _pthread_wqthread + 1022
13 libsystem_pthread.dylib 0x20a3c9fc start_wqthread + 6
The crashes only appears on iOS9, none whatsoever on iOS8, but this could just be a coincidence. I am also seeing this via Crittercism breadcrumbs:
I am also using Background Fetches which do hit the network layer.
Any idea why this is happing?
This looks to me like a bug with Crittercism. The class CRNSURLSessionTaskProxy is a Crittercism class (see below), so it's crashing in their code, which is corroborated by the errors in the Crittercism breadcrumbs.
The only Google hit (other than this question) for the class name is this one. If you look at the other classes in that dump that start with CR, you will see CRBreadcrumbs and CRCrash.
Also here's a dump of the Crittercism framework in the Hopper disassembler:
Pretty conclusive I would say.
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
This is the crash report I received from crashlytics and I don't have the slightest clue on what it means or what to do about this. Any tips or suggestions will be appreciated.
Thread : Crashed: NSOperationQueue Serial Queue
0 libsystem_platform.dylib 0x3baef4da _platform_memmove$VARIANT$Swift + 185
1 ??? 0x0000000c
2 DataDetectorsCore 0x350b26bb DDTokenCacheGetItemAtIndexCreateIfNeeded + 90
3 DataDetectorsCore 0x350b2635 DDTokenCacheGetTokensAtPosition + 1084
4 DataDetectorsCore 0x350ae41d _DDScannerHandleState + 472
5 DataDetectorsCore 0x350aea71 _DDScannerHandleState + 2092
6 DataDetectorsCore 0x350addf1 DDScannerScanQuery + 328
7 DataDetectorsUI 0x350c8f7d -[DDOperation main] + 288
8 Foundation 0x31664aa5 -[__NSOperationInternal _start:] + 772
9 Foundation 0x3170896d __NSOQSchedule_f + 60
10 libdispatch.dylib 0x3b9c5e7b _dispatch_queue_drain + 374
11 libdispatch.dylib 0x3b9c2f93 _dispatch_queue_invoke + 42
12 libdispatch.dylib 0x3b9c6745 _dispatch_root_queue_drain + 76
13 libdispatch.dylib 0x3b9c69c5 _dispatch_worker_thread2 + 56
14 libsystem_pthread.dylib 0x3baf0dff _pthread_wqthread + 298
Do you have any part of your app where the user clicks on a URL or specifies a URL which is then handled by your app, or by the system on behalf of your app. The subsystem that does this is DataDetectorsCore.
If you have code around that area, it would be a good idea to add log messages, assert checks, validation, and unit test code.
It might be that you are receiving maliciously crafted URLs; here is an example but for the Mac platform: http://nakedsecurity.sophos.com/2013/02/06/anatomy-of-a-bug-how-mac-os-x-chokes-if-you-type-file/
I am getting a weird timeout crash via iTunes during app launch. Here is the stack trace. Seems like something to do with the location service (yes, I do ask for a user's location). Does anyone have any experience with such a crash?
Thread 10 name: Dispatch queue: com.apple.locationd.registration.xpcq
Thread 10:
0 libsystem_kernel.dylib 0x313dd2c8 semaphore_timedwait_trap
1 libdispatch.dylib 0x322db0e6 _dispatch_semaphore_wait_slow
2 libdispatch.dylib 0x322db154 dispatch_semaphore_wait$VARIANT$up
3 CoreLocation 0x349cd838 CLClientInvokeCallback(__CLClient*, CLClientEvent, __CFDictionary const*)
4 CoreLocation 0x349cffc0 ___CLClientCreateConnection_block_invoke_0
5 CoreLocation 0x34a00c06 CLConnection::handleMessage(CLConnectionMessage*)
6 CoreLocation 0x34a01a14 __setEventHandler_block_invoke_0
7 libxpc.dylib 0x349c190a __XPC_CONNECTION_FAULT_BOUNDARY__
8 libxpc.dylib 0x349badae _xpc_connection_recv_message
9 libxpc.dylib 0x349bab5e _xpc_connection_wakeup_recv
10 libxpc.dylib 0x349baa24 _xpc_connection_wakeup2
11 libxpc.dylib 0x349ba462 _xpc_connection_wakeup
12 libdispatch.dylib 0x322dc21e _dispatch_source_invoke
13 libdispatch.dylib 0x322d9b70 _dispatch_queue_invoke$VARIANT$up
14 libdispatch.dylib 0x322d9caa _dispatch_queue_drain
15 libdispatch.dylib 0x322d9b66 _dispatch_queue_invoke$VARIANT$up
16 libdispatch.dylib 0x322d9caa _dispatch_queue_drain
17 libdispatch.dylib 0x322d9b66 _dispatch_queue_invoke$VARIANT$up
18 libdispatch.dylib 0x322da76c _dispatch_worker_thread2
19 libsystem_c.dylib 0x3351d4b0 _pthread_wqthread
20 libsystem_c.dylib 0x3351d384 start_wqthread
I had a similar issue. I resolved it by rebooting my iOS device entirely.
I believe the issue is that the remote debug server is in an unexpected state and causing the app to break the running application (libxpc is involved in remote debugging I believe). As a result the best way to clean this up is to simply reboot.