FMDBBlockSQLiteCallBackFunction Crash dans une application qui n'utilise pas makeFunctionNamed

102

Je travaille sur une application qui se trouve dans l'App Store, qui utilise FMDBpour interagir avec sa base de données sqlite. Nous avons reçu des rapports d'erreur avec des traces de pile comme ceci:

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

Cependant, à la lecture du FMDBcode, il semble être FMDBBlockSQLiteCallBackFunctionappelé uniquement comme rappel pour les SQLitefonctions créées à l'aide de FMDatabasela makeFunctionNamed:maximumArguments:withBlock:méthode de, que nous n'utilisons pas du tout.

Des idées sur ce qui pourrait causer des plantages comme celui-ci?

Greg
la source
Cela s'est-il produit après une mise à jour de l'application ou après que quelque chose d'autre ait été modifié ou simplement à l'improviste?
Non, cela se produit sporadiquement depuis le lancement. Nous n'avons pas été en mesure de reproduire en interne, et ne disposons que des rapports de plantage à ce stade.
Greg
1
Ce didFinishsymbole peut être un indice. Peut-être avez-vous une sorte de condition de race. C'est-à-dire que votre matériel de développeur fonctionne plus rapidement que le matériel de certains de vos utilisateurs, vous ne voyez donc pas le problème se produire. Je vous recommande d'enliser votre matériel d'une manière ou d'une autre et de voir si le problème apparaît pour vous. Si tel est le cas, le débogage à partir de là devrait être facile.
donjuedo
Je pense que les symboles dans la trace de pile peuvent être incorrects. Je viens de tomber sur un crash dans une version de développement de l'application qui semble identique en termes de fil d'Ariane que je connecte avec CLS_LOG, et il s'agissait d'un cas où un délégué non lié à FMDB n'était pas défini sur zéro sur dealloc.
Greg
@Greg Avez-vous plus d'informations à ce sujet? Nous constatons la même chose dans l'une de nos applications. Utilisiez-vous ARC?
funkybro

Réponses:

1

Les didFinishfait ressembler à vous pouvez avoir une condition de course sur cette ligne:

6  CFNetwork                      0x00000001851475a4 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 300

Essayez d'émuler un matériel lent pour reproduire l'état de l'utilisateur final.

Kirk Strobeck
la source