Hi, Teg,
On Mon, Jan 25, 2016 at 11:31 AM, Teg <Teg at djii.com> wrote:
> 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.
Does not make a difference.
I added that function and call it from the MainFrame destructor.
It still crashed.
Thank you.
>
>
> 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
>
