Re: [sqlite] Severe documentation bug in sqlite3_close leading to crash
Am 26.07.2008 um 17:21 schrieb Stephen Woodbridge:
> Hartwig Wiesmann wrote:
>> The latest sqlite3_close(sqlite3*) documentation states:
>>
>> Applications should finalize all prepared statements and close all
>> BLOB handles associated with the sqlite3 object prior to attempting
>> to
>> close the object. The sqlite3_next_stmt() interface can be used to
>> locate all prepared statements associated with a database connection
>> if desired. Typical code might look like this:
>>
>> sqlite3_stmt *pStmt;
>> while( (pStmt = sqlite3_next_stmt(db, 0))!=0 ){
>> sqlite3_finalize(pStmt);
>> }
>> This is dangerous and does NOT always work!
>> Actually, this causes a terrible bug in the RTree module: the rtree
>> module stores dynamically 9 prepared statement (see rtreeSqlInit). If
>> now all prepared statements are closed before sqlite3_close is called
>> these statements are also finalized.
>> Now, sqlite3_close is called. This call also terminates the rtree
>> module. But this module does not know that the prepared and stored
>> statements (pointers to the previously prepared statements) have
>> already been finalized and do not exist anymore. So, it tries to
>> clean
>> up the not anymore existing part again and crashes!
>>
>> Any workarounds are welcome!!
>
> Seems like the sqlite3_finalize() should check if the pointer is null
> before destroying it, and after destroying it set the freed pointers
> to
> NULL so that they are not destroyed again. Or do the equivalent if
> they
> are not all pointers.
>
> Then again maybe I should not comment without looking at the code :)
> that works pretty darn well most all the time for me.
>
None of the pointers have the value null because the pointers in the
rtree module are not modified by the finalize statement (actually the
finalize statement does not know that there are a couple of pointers
pointing to the non-finalized statement).
Hartwig
> -Steve
> ___
> 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
Re: [sqlite] Severe documentation bug in sqlite3_close leading to crash
Hartwig Wiesmann wrote:
> The latest sqlite3_close(sqlite3*) documentation states:
>
> Applications should finalize all prepared statements and close all
> BLOB handles associated with the sqlite3 object prior to attempting to
> close the object. The sqlite3_next_stmt() interface can be used to
> locate all prepared statements associated with a database connection
> if desired. Typical code might look like this:
>
> sqlite3_stmt *pStmt;
> while( (pStmt = sqlite3_next_stmt(db, 0))!=0 ){
> sqlite3_finalize(pStmt);
> }
> This is dangerous and does NOT always work!
> Actually, this causes a terrible bug in the RTree module: the rtree
> module stores dynamically 9 prepared statement (see rtreeSqlInit). If
> now all prepared statements are closed before sqlite3_close is called
> these statements are also finalized.
> Now, sqlite3_close is called. This call also terminates the rtree
> module. But this module does not know that the prepared and stored
> statements (pointers to the previously prepared statements) have
> already been finalized and do not exist anymore. So, it tries to clean
> up the not anymore existing part again and crashes!
>
> Any workarounds are welcome!!
Seems like the sqlite3_finalize() should check if the pointer is null
before destroying it, and after destroying it set the freed pointers to
NULL so that they are not destroyed again. Or do the equivalent if they
are not all pointers.
Then again maybe I should not comment without looking at the code :)
that works pretty darn well most all the time for me.
-Steve
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Severe documentation bug in sqlite3_close leading to crash
The latest sqlite3_close(sqlite3*) documentation states:
Applications should finalize all prepared statements and close all
BLOB handles associated with the sqlite3 object prior to attempting to
close the object. The sqlite3_next_stmt() interface can be used to
locate all prepared statements associated with a database connection
if desired. Typical code might look like this:
sqlite3_stmt *pStmt;
while( (pStmt = sqlite3_next_stmt(db, 0))!=0 ){
sqlite3_finalize(pStmt);
}
This is dangerous and does NOT always work!
Actually, this causes a terrible bug in the RTree module: the rtree
module stores dynamically 9 prepared statement (see rtreeSqlInit). If
now all prepared statements are closed before sqlite3_close is called
these statements are also finalized.
Now, sqlite3_close is called. This call also terminates the rtree
module. But this module does not know that the prepared and stored
statements (pointers to the previously prepared statements) have
already been finalized and do not exist anymore. So, it tries to clean
up the not anymore existing part again and crashes!
Any workarounds are welcome!!
Hartwig
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
