FMDBBlockSQLiteCallBackFunction Crash in app that's not using makeFunctionNamed
Asked Answered
F

1

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?

Frow answered 8/6, 2015 at 16:17 Comment(11)
Did this happen after an app-update or after something else got changed or just out of the blue?Myotome
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.Frow
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.Braided
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.Frow
@Frow Any more information on this? We are seeing the same in one of our apps. Were you using ARC?Gamone
@Frow 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?Lance
@Gamone 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.Frow
Have you set a breakpoint on the method in question? Try a symbolic breakpoint to see exactly when it's getting called.Worthless
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.Frow
@Frow You should add what you did as an answer.Monaghan
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...)Purple
C
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.

Chauffer answered 26/7, 2016 at 5:56 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.