FMDBBlockSQLiteCallBackFunction Сбой в приложении, которое не использует makeFunctionNamed


102

Я работаю над приложением из магазина приложений, которое используется FMDBдля взаимодействия со своей базой данных sqlite. Мы получили несколько отчетов о сбоях с такими трассировками стека:

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

Однако, от чтения FMDBкоды выглядит как FMDBBlockSQLiteCallBackFunctionназываются только как функция обратного вызова для SQLiteфункций создается с помощью FMDatabase«s makeFunctionNamed:maximumArguments:withBlock:метода, который мы не используем вообще.

Есть идеи, что может вызывать такие сбои?


Произошло ли это после обновления приложения, или после того, как что-то еще изменилось, или просто неожиданно?

Нет, с момента запуска это происходило спорадически. Мы не смогли воспроизвести это самостоятельно, и на данный момент у нас есть только отчеты о сбоях.
Грег,

1
Этот didFinishсимвол может быть намеком. Возможно, у вас что-то вроде гонки. Т.е. оборудование вашего разработчика работает быстрее, чем оборудование некоторых пользователей, поэтому вы не видите, что проблема возникает. Я бы рекомендовал как-то увязнуть ваше оборудование и посмотреть, не возникнет ли у вас проблема. Если да, то отладка оттуда должна быть простой.
donjuedo

Я думаю, что символы в трассировке стека могут быть неправильными. Я только что столкнулся с ошибкой в ​​сборке разработки приложения, которая выглядит идентично с точки зрения хлебных крошек, которые я регистрирую с помощью CLS_LOG, и это был случай, когда делегат, не связанный с FMDB, не был установлен в ноль при освобождении.
Грег

@Greg Есть еще информация по этому поводу? То же самое мы наблюдаем в одном из наших приложений. Вы использовали ARC?
funkybro

Ответы:


1

В didFinishон выглядит , как вы , возможно, состояние гонки на этой линии:

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

Попробуйте имитировать медленное оборудование, чтобы воспроизвести состояние конечного пользователя.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.