102

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?

Rafayet Ullah
  • 1,108
  • 4
  • 14
  • 27
Greg
  • 33,450
  • 15
  • 93
  • 100
  • Did this happen after an app-update or after something else got changed or just out of the blue? –  Jun 12 '15 at 18:57
  • No, this has been happening sporadically since launch. We have not been able to reproduce in house, and only have the crash reports to go by at this point. – Greg Jun 12 '15 at 20:21
  • 1
    That `didFinish` symbol may be a hint. Perhaps you have a race condition of sorts. I.e., your developer hardware runs faster than some of your users' hardware, so you don't see the problem occur. I'd recommend bogging down your hardware somehow, and see if the problem appears for you. If so, debugging from there should be easy. – donjuedo Jun 17 '15 at 19:51
  • I think the symbols in the stack trace may be incorrect. I just came across a crash in a development build of the app that looks identical in terms of the breadcrumbs that I'm logging with CLS_LOG, and it was a case of an unrelated to FMDB delegate not being set to nil on dealloc. – Greg Jun 17 '15 at 20:45
  • @Greg Any more information on this? We are seeing the same in one of our apps. Were you using ARC? – funkybro Aug 17 '15 at 10:46
  • @Greg have you initialized the FMDB in the `appDidFinishedLaunch ` ? It seems there was a thread dispatched and also `NSBlockOperation` created. I guess this is thread issue. So in which thread you have initialized FMDB? – Shamim Hossain Oct 13 '15 at 03:39
  • @funkybro sorry for not responding to your earlier comment. We had several classes which used a custom delegate protocol, and there were a few places in our code where the delegate wasn't getting set to nil. After cleaning up these places, the crashes stopped. I don't know why FMDB's callback functions were appearing in the stack trace, as FMDB wasn't directly involved in these delegates. – Greg Jan 26 '16 at 23:53
  • Have you set a breakpoint on the method in question? Try a symbolic breakpoint to see exactly when it's getting called. – Moshe Feb 01 '16 at 23:21
  • Yes, we tried setting breakpoints. Just to be clear, our problem that was occurring last June has already been resolved as I described in my comments, and has not reoccurred since. – Greg Feb 03 '16 at 23:29
  • @Greg You should add what you did as an answer. – Harry Apr 30 '16 at 04:52
  • I'm not really a Mac/IOS specialist, but it looks like the symbols are not correctly resolved, so the stack generate, made a stab at the symbol (and got it wrong...) – mksteve May 30 '16 at 19:25

1 Answers1

1

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.

Kirk Strobeck
  • 17,984
  • 20
  • 75
  • 114