FMDBBlockSQLiteCallBackFunction Arresto anomalo in un'app che non utilizza makeFunctionNamed


102

Sto lavorando a un'app che si trova nell'app store, che utilizza FMDBper interagire con il suo database sqlite. Abbiamo ricevuto alcuni rapporti sugli arresti anomali con tracce dello stack come questa:

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

Tuttavia, dalla lettura del FMDBcodice sembra che FMDBBlockSQLiteCallBackFunctionvenga chiamato solo come callback per le SQLitefunzioni create usando FMDatabaseil makeFunctionNamed:maximumArguments:withBlock:metodo di, che non stiamo usando affatto.

Qualche idea su cosa potrebbe causare arresti anomali come questo?


È accaduto dopo un aggiornamento dell'app o dopo che qualcos'altro è stato modificato o semplicemente all'improvviso?

No, è successo sporadicamente dal lancio. Non siamo stati in grado di riprodurre internamente e, a questo punto, abbiamo solo i rapporti sugli arresti anomali.
Greg

1
Quel didFinishsimbolo potrebbe essere un suggerimento. Forse hai una sorta di condizione di gara. Cioè, l'hardware del tuo sviluppatore è più veloce dell'hardware di alcuni dei tuoi utenti, quindi non vedi che si verifica il problema. Consiglierei di impantanare il tuo hardware in qualche modo e vedere se il problema appare per te. In tal caso, il debug da lì dovrebbe essere facile.
donjuedo

Penso che i simboli nella traccia dello stack possano essere errati. Mi sono appena imbattuto in un arresto anomalo in una build di sviluppo dell'app che sembra identica in termini di breadcrumb che sto registrando con CLS_LOG ed è stato un caso di un delegato non correlato a FMDB che non è stato impostato su zero su dealloc.
Greg

@ Greg Altre informazioni su questo? Stiamo vedendo lo stesso in una delle nostre app. Stavi usando ARC?
funkybro

Risposte:


1

Gli didFinishfa apparire come si può avere una condizione di competizione su questa linea:

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

Prova a emulare l'hardware lento per riprodurre lo stato dell'utente finale.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.