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&v2=d05529e749a4f10b&sbs=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
