Igor, You can't safely pass a SQLite handle between different SQL DLLs that way if they're both built with their own copy of the amalgamation (or link to things built with different copies). SQLite uses a handful of global variables, but each DLL has its own copy of each of these global variables and they can and will have different values, which can mess things up. I ran into a version of this problem when I tried to load a 2nd DLL built with its own copy of the sqlite3.c amalgamation. I fixed that by exposing the SQLite3 entrypoints in the first DLL and linking the second DLL against it so there was only one copy of the amalgamation used for that SQLite3 handle.
Peter On 1/24/2016 10:18 PM, Igor Korot wrote: > Hi, ALL, > I have a strange problem. > > I am trying to use sqlite in my program. It has a main application and > couplef DLLs. > > I am getting the connection in one of the DLL, then the pointer is passed up > to the main application. > > Upon exiting from the application I'm trying to close the connection and > delete all the memory. > > Unfortunately upon exiting the application it crashes inside > sqlite3_mutex_enter(). > The comment above the function says: > > [quote] > /* > ** Obtain the mutex p. If some other thread already has the mutex, block > ** until it can be obtained. > */ > [/quote] > > The DLL does not start any threads, in fact the application will be 1 > thread only. > So is there some compile-time switch I should use to mitigate the issue? > > Moreover I don't understand why am I getting the assertion - there is no MT > involved. > > Can someone shed some lights? > > Thank you. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
