System.Data.SQLite
View Ticket
Not logged in
Ticket UUID: 2ce0870faddbb26fe1a348d9423e7476edbde9d6
Title: Exception from logging initialization after library initialization
Status: Closed Type: Code_Defect
Severity: Critical Priority: Blocker
Subsystem: Logging Resolution: Fixed
Last Modified: 2011-11-19 04:13:15
Version Found In: 1.0.76.0
Description:
We use SQLite as an application file format, and the primary back-end code that deals with the database runs in a non-default AppDomain. One of our feature requires that we occasionally create an additional SQLiteConnection to a separate database while running in the default AppDomain. The non-default AppDomain use of SQLite will always occur *before* the default AppDomain use.

After upgrading from 1.0.66.0 to 1.0.76.0, we receive a SQLiteException with the message "Library used incorrectly" and "Failed to initialize logging". As far as I can tell, what's happening is logging initialization is skipped when we first create a connection (due to the IsDefaultAppDomain() check in SQLiteLog.Initialize()), and then logging tries to initialize when we subsequently create another connection in the default AppDomain, but sqlite3_config() fails because sqlite3_initialize() has already been called since the library is already in use.

I thought the Force_SQLite log environment variable might be usable as a workaround, but setting it will just cause logging to be initialized multiple times since SQLiteLog._callback is a static (and thus there each AppDomain has its own copy).

It seems to me that either logging init should be restricted to the first AppDomain to attempt it (instead of the default AppDomain every time) or it should be short-circuited if sqlite3_initialize() has already been called.

Note that we have our own private build of the library; we can modify it to work around this problem so a fix is not urgently needed.


mistachkin added on 2011-11-16 01:55:00 UTC:
Thanks for the report. This issue is being worked on and will be fixed prior to 1.0.77.0.


mistachkin added on 2011-11-16 03:09:10 UTC:
Fixed by trunk check-in [f48d1b0376]. Please let me know if this fix works in your environment.


anonymous claiming to be Jonathan Little added on 2011-11-19 04:13:15 UTC:
That was quick!

Confirmed it fixes the problem in our build, thanks!