Buffer overflow issues can cause problems at seemingly random points in a
program. I've worked on some really nasty ones before when no debugging was
available.
If dbRef is being corrupted then put a dbRef check in your program in every
function at beginning and end.
int dbRefCheck(sqlite3 *dbRef)
{
static sqlite3 *mydbRef;
if (dbRef == NULL) mydbRef = dbRef;
if (dbRef != mydbRef) return true;
return false;
}
if (dbRefCheck(dbRef)) {
// error output -- with FILE and LINE macros if you have them. Otherwise
some other unique id for each call so you know where it's happening.
}
Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Advanced GEOINT Solutions Operating Unit
Northrop Grumman Information Systems
________________________________
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Rick Maddy [rma...@gmail.com]
Sent: Thursday, July 19, 2012 11:46 AM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] Getting occasional crashes with sqlite3_prepare_v2
and sqlite3_step in iOS app
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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
