> For quite some time now I've been getting reports of crashes in my iOS app.
> Specifically these are caused by crashes in sqlite3_prepare_v2 and
> sqlite_step. The associated code works fine most of the time. So I'm looking
> for thoughts on how to find and fix the problem since there seems to be no
> pattern to when the rare crashes actually happen.
All the above means that your application corrupts memory somewhere
and it's not related to SQLite in any way. SQLite here is just an
unfortunate victim tripping over your memory corruption.
I don't know though if there are any tools on iOS for memory debugging.
Pavel
On Thu, Jul 19, 2012 at 12:09 PM, Rick Maddy <rma...@gmail.com> wrote:
> For quite some time now I've been getting reports of crashes in my iOS app.
> Specifically these are caused by crashes in sqlite3_prepare_v2 and
> sqlite_step. The associated code works fine most of the time. So I'm looking
> for thoughts on how to find and fix the problem since there seems to be no
> pattern to when the rare crashes actually happen.
>
> Here is some background information:
>
> All of the issues are from devices running iOS 5.1.1 which has sqlite version
> 3.7.7. I open the database on app startup with the following call:
>
> if (sqlite3_open_v2([dbPath UTF8String], &dbRef,
> SQLITE_OPEN_READWRITE | SQLITE_OPEN_FULLMUTEX, NULL) == SQLITE_OK) {
> }
>
> I use the same 'dbRef' for every query performed in the app regardless of the
> thread the query is used on.
>
> The output of 'sqlite3_threadsafe()' is 2 (SQLITE_CONFIG_SERIALIZED I
> believe). So the database should be properly setup to work in a
> multi-threaded environment.
>
> Every call to 'sqlite3_prepare_v2' that I use basically looks like this:
>
> sqlite3_stmt *query = nil;
> NSString *sql = @"some valid SQL";
> sqlite3_prepare_v2(dbRef, [sql UTF8String], -1, &query, nil);
>
>
> Here are a few examples of the stack traces from the crash reports:
>
> Sample 1:
>
> Exception Type: SIGSEGV
> Exception Codes: SEGV_ACCERR at 0x1a
> Crashed Thread: 0
>
> Thread 0 Crashed:
> 0 libsqlite3.dylib 0x34c783cc 0x34c43000 + 218060
> 1 libsqlite3.dylib 0x34c5d3bd 0x34c43000 + 107453
> 2 libsqlite3.dylib 0x34c4d5bb 0x34c43000 + 42427
> 3 libsqlite3.dylib 0x34c4ab7b 0x34c43000 + 31611
> 4 libsqlite3.dylib 0x34c4a367 0x34c43000 + 29543
> 5 libsqlite3.dylib 0x34c49e95 0x34c43000 + 28309
> 6 libsqlite3.dylib 0x34c49beb 0x34c43000 + 27627
> 7 libsqlite3.dylib 0x34c80f97 sqlite3_prepare_v2 + 27
>
> ===================
>
> Sample 2:
>
> Exception Type: SIGSEGV
> Exception Codes: SEGV_ACCERR at 0x7
> Crashed Thread: 0
>
> Thread 0 Crashed:
> 0 libsqlite3.dylib 0x34f38410 0x34f1e000 + 107536
> 1 libsqlite3.dylib 0x34f2819f 0x34f1e000 + 41375
> 2 libsqlite3.dylib 0x34f25b7b 0x34f1e000 + 31611
> 3 libsqlite3.dylib 0x34f25367 0x34f1e000 + 29543
> 4 libsqlite3.dylib 0x34f24e95 0x34f1e000 + 28309
> 5 libsqlite3.dylib 0x34f24beb 0x34f1e000 + 27627
> 6 libsqlite3.dylib 0x34f5bf97 sqlite3_prepare_v2 + 27
>
> ===================
>
> Sample 3:
>
> Exception Type: SIGSEGV
> Exception Codes: SEGV_ACCERR at 0x2
> Crashed Thread: 7
>
> Thread 7 Crashed:
> 0 libsqlite3.dylib 0x34cf848c 0x34cc8000 + 197772
> 1 libsqlite3.dylib 0x34cfd8f9 0x34cc8000 + 219385
> 2 libsqlite3.dylib 0x34cf84ed 0x34cc8000 + 197869
> 3 libsqlite3.dylib 0x34cf0bdd 0x34cc8000 + 166877
> 4 libsqlite3.dylib 0x34cef6c9 sqlite3_step + 2105
>
> ===================
>
> Thanks for any insights into these issues.
>
> Rick
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
