I'm working on an app that's in the app store, which uses FMDB for interacting with its sqlite database. We've received some crash reports with stack traces like this:
Thread : Crashed: NSOperationQueue 0x170239c20 :: NSOperation 0x17024d7d0 (QOS: LEGACY)
0 libobjc.A.dylib 0x000000019701c0b4 objc_retain + 20
1 MyApp 0x00000001002bdff4 FMDBBlockSQLiteCallBackFunction
2 MyApp 0x00000001002bdb1c FMDBBlockSQLiteCallBackFunction
3 MyApp 0x00000001002b66b4 FMDBBlockSQLiteCallBackFunction
4 MyApp 0x00000001002980fc FMDBBlockSQLiteCallBackFunction
5 MyApp 0x000000010029f20c FMDBBlockSQLiteCallBackFunction
6 CFNetwork 0x00000001851475a4 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 300
7 Foundation 0x00000001866bf1c4 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
8 Foundation 0x0000000186610604 -[NSBlockOperation main] + 96
9 Foundation 0x00000001866001cc -[__NSOperationInternal _start:] + 636
10 Foundation 0x00000001866c1f28 __NSOQSchedule_f + 228
11 libdispatch.dylib 0x0000000197655954 _dispatch_client_callout + 16
12 libdispatch.dylib 0x00000001976600a4 _dispatch_queue_drain + 1448
13 libdispatch.dylib 0x0000000197658a5c _dispatch_queue_invoke + 132
14 libdispatch.dylib 0x0000000197662318 _dispatch_root_queue_drain + 720
15 libdispatch.dylib 0x0000000197663c4c _dispatch_worker_thread3 + 108
16 libsystem_pthread.dylib 0x000000019783522c _pthread_wqthread + 816
However, from reading the FMDB code it looks like FMDBBlockSQLiteCallBackFunction is only called as the callback for SQLite functions created using FMDatabase's makeFunctionNamed:maximumArguments:withBlock: method, which we're not using at all.
Any ideas what could be causing crashes like this?
The didFinish makes it look like you may have a race condition on this line:
6 CFNetwork 0x00000001851475a4 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 300
Try to emulate slow hardware to reproduce the end user’s state.
Related
My app is working well and I didn't get this error on Xcode 13.4,
Is it Xcode 14 beta bug or I'm doing some bad threading?!
Thread running at QOS_CLASS_USER_INITIATED waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversions
I didn't understand the issue, so I added my stack log too:
_TtGC7SwiftUI14_UIHostingViewVVS_P10$1dc8d4d8821BridgedNavigationView8RootView_ implements focusItemsInRect: - caching for linear focus movement is limited as long as this view is on screen.
2022-06-07 18:53:41.412342+0430 MyApp[916:25641] [UIFocus] _TtCC7SwiftUI17HostingScrollView22PlatformGroupContainer implements focusItemsInRect: - caching for linear focus movement is limited as long as this view is on screen.
Thread Performance Checker: Thread running at QOS_CLASS_USER_INITIATED waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversionsPID: 916, TID: 25815
Backtrace
=================================================================
3 MyApp 0x0000000102c7665c -[_FSRRunLoopThread runLoop] + 44
4 MyApp 0x0000000102c763a8 __45+[NSRunLoop(FSRWebSocket) FSR_networkRunLoop]_block_invoke + 124
5 libdispatch.dylib 0x00000001054318fc _dispatch_client_callout + 16
6 libdispatch.dylib 0x0000000105433240 _dispatch_once_callout + 80
7 MyApp 0x0000000102c76304 +[NSRunLoop(FSRWebSocket) FSR_networkRunLoop] + 84
8 MyApp 0x0000000102c6ff30 -[FSRWebSocket _connect] + 68
9 MyApp 0x0000000102c6ed60 -[FSRWebSocket open] + 216
10 MyApp 0x0000000102c4ebdc -[FWebSocketConnection open] + 248
11 MyApp 0x0000000102c4d3c4 -[FConnection open] + 112
12 MyApp 0x0000000102bf1404 -[FPersistentConnection openNetworkConnectionWithContext:] + 588
13 MyApp 0x0000000102bf1078 __45-[FPersistentConnection tryScheduleReconnect]_block_invoke_2 + 332
14 MyApp 0x0000000102c3d0fc -[FIRDatabaseConnectionContextProvider fetchContextForcingRefresh:withCallback:] + 264
15 MyApp 0x0000000102bf0f0c __45-[FPersistentConnection tryScheduleReconnect]_block_invoke + 460
16 MyApp 0x0000000102c1c0d8 -[FIRRetryHelperTask execute] + 92
17 MyApp 0x0000000102c1c6dc __24-[FIRRetryHelper retry:]_block_invoke + 84
18 libdispatch.dylib 0x00000001054300c4 _dispatch_call_block_and_release + 24
19 libdispatch.dylib 0x00000001054318fc _dispatch_client_callout + 16
20 libdispatch.dylib 0x0000000105438a58 _dispatch_lane_serial_drain + 688
21 libdispatch.dylib 0x00000001054396d0 _dispatch_lane_invoke + 424
22 libdispatch.dylib 0x0000000105445150 _dispatch_workloop_worker_thread + 696
23 libsystem_pthread.dylib 0x000000023db94ddc _pthread_wqthread + 284
24 libsystem_pthread.dylib 0x000000023db94908 start_wqthread + 8
You're getting this message due to a priority inversion in your code. More details here: https://developer.apple.com/documentation/xcode/diagnosing-performance-issues-early
More specifically, you're using dispatch_group_wait which doesn't provide priority inversion avoidance; so your waiting thread is susceptible to an inversion. Seemingly that's what's happening here.
I am getting a crash on the live app I am working on and I can't seem to recreate or find the issue. This is the crash output:
`Crashed: NSOperationQueue 0x123e7d5c0 (QOS: UNSPECIFIED)
0 libobjc.A.dylib 0x184a52198 objc_release + 104
1 Foundation 0x1850bd930 NSKeyValuePopPendingNotificationLocal + 60
2 Foundation 0x1850bd8ac NSKeyValueDidChange.llvm.947807775919258276 + 364
3 Foundation 0x1850bd2e0 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] + 624
4 Foundation 0x18500cb1c -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 68
5 Foundation 0x1850b8eb8 _NSSetLongLongValueAndNotify + 284
6 CFNetwork 0x1880f4470 _CFNetworkHTTPConnectionCacheSetLimit + 205660
7 Foundation 0x1850d5410 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
8 Foundation 0x184fdf138 -[NSBlockOperation main] + 100
9 Foundation 0x1850d7698 __NSOPERATION_IS_INVOKING_MAIN__ + 20
10 Foundation 0x184fdedd0 -[NSOperation start] + 732
11 Foundation 0x1850d8090 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 20
12 Foundation 0x1850d7b5c __NSOQSchedule_f + 180
13 libdispatch.dylib 0x18498f7dc _dispatch_block_async_invoke2 + 104
14 libdispatch.dylib 0x1849dd184 _dispatch_client_callout + 16
15 libdispatch.dylib 0x184985a3c _dispatch_continuation_pop$VARIANT$mp + 412
16 libdispatch.dylib 0x184985190 _dispatch_async_redirect_invoke + 600
17 libdispatch.dylib 0x184991fa4 _dispatch_root_queue_drain + 376
18 libdispatch.dylib 0x184992770 _dispatch_worker_thread2 + 128
19 libsystem_pthread.dylib 0x184a2cb48 _pthread_wqthread + 212
20 libsystem_pthread.dylib 0x184a2f760 start_wqthread + 8`
Please help me to figure out this thing. Thanks
It is caused by FirebasePerformance v3.3.1 and XCode 12. Use 'FirebasePerformance', '3.3.0' should solve the problem.
After setting FirebasePerformance to v3.3.0, we did not see any NSKeyValuePopPendingNotificationLocal, AFURLSessionManager, NSKVODeallocate, CFDictionaryGetValue, NSKeyValueWillChange, [NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:]... crashes anymore.
The crash-free percentage is recovered from 95% to 99.9%.
We removed Firebase Performance and since then we have not detected crashes anymore. The problem I think is due to Firebase Performance 3.3.1 with Xcode 12.
I have the same problem. My solution was to lower the version of Firebase. This problem should be caused by Firebase Performance
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've got an odd crash I'm trying to debug, and some help would be most appreciated.
My main thread crashes like so:
Thread : Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x3316ddfc __pthread_kill + 8
1 libsystem_pthread.dylib 0x331ebd37 pthread_kill + 62
2 libsystem_c.dylib 0x3310d909 abort + 76
3 libc++abi.dylib 0x324389c9 __cxa_bad_cast
4 libc++abi.dylib 0x3244fe29 std::__terminate(void (*)()) + 148
5 libc++abi.dylib 0x3244f8af __cxa_rethrow + 102
6 libobjc.A.dylib 0x32b27dd3 objc_exception_rethrow + 42
7 CoreFoundation 0x2522245d CFRunLoopRunSpecific + 632
8 CoreFoundation 0x252221d3 CFRunLoopRunInMode + 106
9 GraphicsServices 0x2c5da0a9 GSEventRunModal + 136
10 UIKit 0x28831fa1 UIApplicationMain + 1440
11 LifeLock Wallet 0x000e98b1 main (main.mm:21)
The other threads looked alright, until I saw this background thread, where I'm generating 2048-bit RSA keys:
Thread : RSA Key Gen Queue
0 libsystem_kernel.dylib 0x3315c064 fsync + 8
1 MyApp 0x00c697f5 unixSync (sqlite3.c:30624)
2 MyApp 0x00c310f5 syncJournal (sqlite3.c:19113)
3 MyApp 0x00c10d47 sqlite3PagerCommitPhaseOne (sqlite3.c:49218)
4 MyApp 0x00c1101d sqlite3BtreeCommitPhaseOne (sqlite3.c:56943)
5 MyApp 0x00c63107 sqlite3VdbeHalt (sqlite3.c:66150)
6 MyApp 0x00c62bd1 sqlite3VdbeExec (sqlite3.c:70841)
7 MyApp 0x00c11f33 sqlite3_step (sqlite3.c:68643)
8 MyApp 0x00c0cfdf sqlite3_exec (sqlite3.c:98380)
9 MyApp 0x000ee3eb +[DBHelper execStringNormal:] (DBHelper.m:88)
10 MyApp 0x000f448b +[DBHelper insertCategories] (DBHelper.m:1373)
11 MyApp 0x000f34ed +[DBHelper createDB] (DBHelper.m:1147)
12 MyApp 0x000ee97b +[DBHelper initSqlite] (DBHelper.m:212)
13 MyApp 0x000ea245 -[MyApp databaseSetup (MyAppDelegate.m:187)
14 MyApp 0x001fcc69 __37-[Security generateRSAKeyPair]_block_invoke (Security.m:317)
15 libdispatch.dylib 0x330877bb _dispatch_call_block_and_release + 10
16 libdispatch.dylib 0x3308f5b1 _dispatch_queue_drain + 952
17 libdispatch.dylib 0x33089f85 _dispatch_queue_invoke + 84
18 libdispatch.dylib 0x33090b9b _dispatch_root_queue_drain + 338
19 libdispatch.dylib 0x33091cd7 _dispatch_worker_thread3 + 94
20 libsystem_pthread.dylib 0x331e8e31 _pthread_wqthread + 668
This caught my eye because of the general flow in my code. In a nutshell:
A GCD background thread is created on app start, to generate my RSA keys.
The class that creates the RSA keys has a protocol to call back to a delegate (in this case, my app delegate), when the keys are ready.
On the same GCD background thread, I call back to my delegate object.
Once my app delegate gets called back, I open my SQLite connection and write to the local DB.
My questions are:
Would writing to the SQLite DB on a background thread cause my 'pthread_kill' crash?
Is it worth serializing my SQLite DB to ensure that, in the event I have other threads writing to SQLite, I stay thread-safe?
Thanks!
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/