I have an application in production that uses Parse.com iOS SDK with local datastore ([PFObject pin]).
Some of our users are getting this crash in production, as we see by the Crashlytics report for the crashing thread:
Thread : Crashed: com.parse.sqlite.db.queue
0 libsqlite3.dylib 0x000000019b269f58 (null) + 9096
1 libsqlite3.dylib 0x000000019b25315c (null) + 85124
2 libsqlite3.dylib 0x000000019b25315c (null) + 85124
3 libsqlite3.dylib 0x000000019b21bd68 (null) + 3028
4 libsqlite3.dylib 0x000000019b2530c0 (null) + 84968
5 libsqlite3.dylib 0x000000019b245848 (null) + 29552
6 libsqlite3.dylib 0x000000019b225794 (null) + 13080
7 libsqlite3.dylib 0x000000019b224634 (null) + 8632
8 libsqlite3.dylib 0x000000019b223734 (null) + 4792
9 libsqlite3.dylib 0x000000019b222fa4 (null) + 2856
10 libsqlite3.dylib 0x000000019b222c5c (null) + 2016
11 Parse 0x00000001009a9c20 -[PFSQLiteDatabase _executeQueryAsync:withArgumentsInArray:cachingEnabled:] (PFSQLiteDatabase.m:178)
12 Bolts 0x000000010061d034 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:334)
13 libdispatch.dylib 0x000000019b5457b0 _dispatch_call_block_and_release + 24
14 libdispatch.dylib 0x000000019b545770 _dispatch_client_callout + 16
15 libdispatch.dylib 0x000000019b55175c _dispatch_queue_drain + 864
16 libdispatch.dylib 0x000000019b549274 _dispatch_queue_invoke + 464
17 libdispatch.dylib 0x000000019b545770 _dispatch_client_callout + 16
18 libdispatch.dylib 0x000000019b553bb0 _dispatch_root_queue_drain + 2140
19 libdispatch.dylib 0x000000019b55334c _dispatch_worker_thread3 + 112
20 libsystem_pthread.dylib 0x000000019b759478 _pthread_wqthread + 1092
My assumption is that this happens when the DB schema changes between application upgrades, but that is almost pure guess.
What I am looking for is to see if anyone knows of any way to prevent this crash from happening, by catching the exception maybe or by setting some SDK configuration properties.
Our pinned objects are just for catching data and user sessions and could be safely deleted if required.
Update: Nov 23 2015
We keep experiencing this issue with the Parse SDK (1.9.1) on application launches. It seems like when the data model changes on the Parse.com backend and differs from the data model of the pinned objects, the application always crashes once. The next time it runs, everything works fine.
Possible steps to reproduce (not 100% sure):
- Load objects from Parse.com
- Pin objects locally
- Close the application entirely
- Update model in Parse.com by adding a new column
- Launch the application
- Repeat steps 1 and 2
- CRASH
- Launch the application again
- Repeat steps 1 and 2
- Everything works fine
Here is another crash report that might help debugging the issue:
Thread : Crashed: com.parse.sqlite.db.queue
0 libsqlite3.dylib 0x19ac05f58 (null) + 9096
1 libsqlite3.dylib 0x19abdc020 (null) + 6984
2 libsqlite3.dylib 0x19abdc020 (null) + 6984
3 libsqlite3.dylib 0x19abdbe2c (null) + 6484
4 libsqlite3.dylib 0x19abc1cc0 (null) + 14404
5 libsqlite3.dylib 0x19abc0634 (null) + 8632
6 libsqlite3.dylib 0x19abbf734 (null) + 4792
7 libsqlite3.dylib 0x19abbefa4 (null) + 2856
8 libsqlite3.dylib 0x19abbec5c (null) + 2016
9 Parse 0x100de8bc8 -[PFSQLiteDatabase _executeQueryAsync:withArgumentsInArray:cachingEnabled:] (PFSQLiteDatabase.m:176)
10 Bolts 0x1006c6fec __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
11 libdispatch.dylib 0x19aee17b0 _dispatch_call_block_and_release + 24
12 libdispatch.dylib 0x19aee1770 _dispatch_client_callout + 16
13 libdispatch.dylib 0x19aeed75c _dispatch_queue_drain + 864
14 libdispatch.dylib 0x19aee5274 _dispatch_queue_invoke + 464
15 libdispatch.dylib 0x19aee1770 _dispatch_client_callout + 16
16 libdispatch.dylib 0x19aeefbb0 _dispatch_root_queue_drain + 2140
17 libdispatch.dylib 0x19aeef34c _dispatch_worker_thread3 + 112
18 libsystem_pthread.dylib 0x19b0f5478 _pthread_wqthread + 1092
19 libsystem_pthread.dylib 0x19b0f5028 start_wqthread + 4
Another one:
Thread : Crashed: com.parse.sqlite.db.queue
0 libsqlite3.dylib 0x195959bb8 (null) + 31936
1 libsqlite3.dylib 0x195959bb4 (null) + 31932
2 libsqlite3.dylib 0x195952108 sqlite3_step + 528
3 Parse 0x100e7e330 -[PFSQLiteDatabaseResult step] (PFSQLiteDatabaseResult.m:39)
4 Parse 0x100e7e2ec -[PFSQLiteDatabaseResult next] (PFSQLiteDatabaseResult.m:35)
5 Parse 0x100e59ce4 __52-[PFOfflineStore _getPointerAsyncWithUUID:database:]_block_invoke (PFOfflineStore.m:897)
6 Bolts 0x100727748 __62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke (BFTask.m:410)
7 Bolts 0x100726fec __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
8 Bolts 0x100724d5c __29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:45)
9 Bolts 0x100725270 -[BFExecutor execute:] (BFExecutor.m:109)
10 Bolts 0x100726f64 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
11 Bolts 0x100726b70 -[BFTask runContinuations] (BFTask.m:308)
12 Bolts 0x1007263e0 -[BFTask trySetResult:] (BFTask.m:200)
13 Bolts 0x100726314 -[BFTask setResult:] (BFTask.m:187)
14 Bolts 0x100727e4c -[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:52)
15 Bolts 0x1007272ac __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
16 Bolts 0x1007270a0 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:360)
17 libdispatch.dylib 0x195c313ac _dispatch_call_block_and_release + 24
18 libdispatch.dylib 0x195c3136c _dispatch_client_callout + 16
19 libdispatch.dylib 0x195c3b4c0 _dispatch_queue_drain + 1216
20 libdispatch.dylib 0x195c34474 _dispatch_queue_invoke + 132
21 libdispatch.dylib 0x195c3d224 _dispatch_root_queue_drain + 664
22 libdispatch.dylib 0x195c3e75c _dispatch_worker_thread3 + 108
23 libsystem_pthread.dylib 0x195e0d2e4 _pthread_wqthread + 816
24 libsystem_pthread.dylib 0x195e0cfa8 start_wqthread + 4
