Hello Igor,

MainFrame::~MainFrame()
{
    delete m_db;  // this is where the crash happens
}

I suspect you need to add a "Close" or destroy function to the DLL and
pass the handle back to the DLL to let it get deleted in the DLL
context and not in the context of the caller.


extern "C" __declspec(dllexport) void DestroyObject(Database *db)
{
      delete db;
}

It was my impression that each DLL got it's own heap so, memory
allocated inside the DLL needs to be free'd inside the DLL. I use
Sqlite in a static lib in my applications.

I  treat  memory  allocated  in  DLL's as being owned by the DLL so, I
typically  pass  it  back  to the DLL to be cleaned up.  It believe it
depends  on what run time library you're using though. If you're using
an RTL where all the DLL's end up using a DLL supplied allocator, this
probably isn't an issue. I tend to dynamic load my DLL's so they don't
all use the same allocator.

C



Monday, January 25, 2016, 11:16:57 AM, you wrote:

IK> Hi, Peter,

IK> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson <pbaronson at att.net> 
wrote:
>> 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.

IK> The SQLite is built only once and with just one version of the code.

IK> Consider following pseudo-code:

IK> In DLL:

IK> BOOL APIENTRY DLLMain()
IK> {
IK> }

IK> extern "C" __declspec(dllexport) Database *CreateObject(Database *db)
IK> {
IK>     db = new SQLiteDatabase();
IK>     db->Connect();
IK>     return db;
IK> }

IK> In the main application:

IK> mainframe.h:

IK> class MainFrame
IK> {
IK> public:
IK>      MainFrame();
IK>      ~MainFrame();
IK>      void ConnectToDb();
IK> private:
IK>      Database *m_db;
IK> };

IK> mainframe.cpp:

IK> void MainFrame::ConnectToDb()
IK> {
IK>     Database *db = NULL;
IK>     LoadLibrary();
IK>     func = GetProcAddress();
IK>     m_db = func( db );
IK> }

IK> MainFrame::~MainFrame()
IK> {
IK>     delete m_db;  // this is where the crash happens
IK> }

IK> The pointer address are the same in DLL and main application MainFrame 
class.
IK> And as I said the crash occurs when it tries to acquire the mutex lock.

IK> Thank you.

>>
>> 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
>>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
IK> _______________________________________________
IK> sqlite-users mailing list
IK> sqlite-users at mailinglists.sqlite.org
IK> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



-- 
 Teg                            mailto:Teg at djii.com

Reply via email to