Thanks. One of the users that reported one of the slqite3_prepare_v2 crashes
also sent me their database. I just ran the 'pragma integrity_check' command on
the database and it reported 'ok' though there was a journal file along with
the database file. But there crash happened during a transaction so that should
be OK.
I'll update my code to check the return value of all prepare statements.
With regard to memory issues, I don't see how this could be the case. One of
the places the app crashes (on rare occasions) is:
sqlite3_stmt *load = nil;
sqlite3_prepare_v2(dbRef, "SELECT some_column FROM some_table WHERE some_id
= ? ORDER BY display_order", -1, &load, nil);
How can memory issues creep into such a simple bit of code? Or could it be that
the dbRef somehow became corrupted?
And come to think of it, how is checking the return value of the prepare
statement going to help if the prepare statement crashes before returning?
Thanks,
Rick
On Jul 19, 2012, at 10:32 AM, Simon Slavin wrote:
>
> On 19 Jul 2012, at 5:09pm, Rick Maddy <rma...@gmail.com> wrote:
>
>> Exception Type: SIGSEGV
>> Exception Codes: SEGV_ACCERR at 0x1a
>
> Those are segfaults. They indicate an attempt by your app to access memory
> which doesn't belong to it. This often but not always happens because the
> memory /did/ once belong to it but has now been released.
>
> First, run
>
> <http://www.sqlite.org/pragma.html#pragma_integrity_check>
>
> to see if your database is corrupt. Then put checks in your code for result
> codes every time you call a function of the SQLite API. For instance,
> sqlite3_prepare_v2() returns a result code you should be checking. Just
> asserting that the int returned is SQLITE_OK will probably be enough.
>
> While putting the checks in, you'll probably notice whatever's causing your
> bug.
>
> Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
