[sqlite] System.Data.SQLite, Virtual Tables, and ThreadAbortException Issues
Yes, this branch does resolve the issue, thanks much! This branch looks to be from the current mainline; I'll apply the fix locally to the 1.0.96.0 released version until the next release of System.Data.SQLite. Thanks, MikeN -Original Message- From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Joe Mistachkin Sent: Tuesday, May 12, 2015 8:43 PM To: 'General Discussion of SQLite Database' Subject: Re: [sqlite] System.Data.SQLite, Virtual Tables, and ThreadAbortException Issues Mike Nicolino wrote: > > The issue is isolated to ThreadAbortException since you can't catch it > and prevent it from being re-thrown. I did find a 'fix' for a similar > issue in SystemData.SQLite back on 10/11/2012: > Thanks for the excellent analysis of the issue. I believe you are completely correct. The previous "fix" was for sqlite3_prepare(), to prevent any leakage of native handles prior to their ownership being "transferred" into an official critical handle object. I've now implemented the necessary changes on a branch, pending more testing, here: https://system.data.sqlite.org/index.html/timeline?r=stepNoThreadAbort Could you test these changes in your environment and let us know if they clear the issue? -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] System.Data.SQLite, Virtual Tables, and ThreadAbortException Issues
Hey Everyone, For reference I'm using version 1.0.95.0 of System.Data.SQLite. I've got System.Data.SQLite embedded in our cloud web service using virtual table modules to access our various data sources. Our IIS is configured to abort requests that exceed a maximum time threshold (required for among other things to prevent a malicious user from sucking up web resources by spawning repeated long running requests). The effect is IIS will abort threads that exceed the time threshold. I'm seeing the GC finalizer get stuck trying to finalize an object in SQLite.Interop, blocking on a critical section (which eventually leads to memory exhaustion). After a lot of digging, I believe the situation is as follows: - Request for a long running query via SQLite starts - SQLite 'step' is called, drops into unmanaged code, enters a critical section, then calls back to managed code for virtual table processing - IIS aborts the thread causing a ThreadAbortException in managed code (Virtual table processing) - Stack starts unrolling due to the ThreadAbortException, which prevents the unmanaged code from releasing the critical section - Finalizer gets stuck trying to acquire the critical section when the underlying System.Data.SQLite object(s) are getting finalized. The issue is isolated to ThreadAbortException since you can't catch it and prevent it from being re-thrown. I did find a 'fix' for a similar issue in SystemData.SQLite back on 10/11/2012: https://system.data.sqlite.org/index.html/fdiff?v1=3994ed2958c14a11=d05529e749a4f10b=1 I don't think the 'step' code is protected in the manner of the above fix (likely unneeded at the time, since virtual tables were not supported and there wasn't a case of 'step' dropping into unmanaged code and then back to managed code). Questions: - Have I evaluated this issue correctly or is there potentially something wrong with my integration? - Presuming this is a bug, does anyone have a workaround suggestion? I'm somewhat hesitant to change the 'step' source in System.Data.SQLite to use the same approach as the 10/11/2012 fix, worrying about other potential side effects. Thanks, MikeN
[sqlite] System.Data.SQLite, Virtual Tables, and ThreadAbortException Issues
Mike Nicolino wrote: > > The issue is isolated to ThreadAbortException since you can't catch it and > prevent it from being re-thrown. I did find a 'fix' for a similar issue > in SystemData.SQLite back on 10/11/2012: > Thanks for the excellent analysis of the issue. I believe you are completely correct. The previous "fix" was for sqlite3_prepare(), to prevent any leakage of native handles prior to their ownership being "transferred" into an official critical handle object. I've now implemented the necessary changes on a branch, pending more testing, here: https://system.data.sqlite.org/index.html/timeline?r=stepNoThreadAbort Could you test these changes in your environment and let us know if they clear the issue? -- Joe Mistachkin
