There appears to be an issue with SQLiteDataReader and its use of the CommandBehavior.CloseConnection flag that can cause an access violation on the GC thread for the underlying statement handle.
<hr /><i>mistachkin added on 2012-10-26 00:27:10 UTC:</i><br />
Test case for this ticket is here: [4960a565c2].
<hr /><i>mistachkin added on 2012-10-26 00:44:50 UTC:</i><br />
The root cause of this issue was the combination of:
1. Using the new sqlite3_close_v2() public API, introduced in 1.0.82.0.
2. Using an extension, such as FTS, that prepares its own statements and finalizes them upon xDisconnect being called on its virtual table.
3. The connection being closed prior to the statement being finalized, in this case through the usage of the CommandBehavior.CloseConnection flag to the SQLiteCommand.ExecuteReader method.
When all of the above conditions were met, the sqlite3_finalize() API ended up being reentrant and freeing the memory used by the connection prematurely, leading to an assert in the DEBUG build.
This issue has been fixed in the SQLite core library and the fix will be present in the next release version of System.Data.SQLite. In the meantime, to work around this issue, avoid using the CommandBehavior.CloseConnection flag and make sure that all SQLiteDataReader and SQLiteCommand objects are disposed prior to disposing or closing the connection associated with them.
<hr /><i>mistachkin added on 2012-10-26 00:59:34 UTC:</i><br />
Fixed in SQLite trunk by check-in [https://www.sqlite.org/src/info/6d42d806ad | 6d42d806ad].
<br>
Fixed in System.Data.SQLite trunk by check-in [e702fa192f].
|
