Hi, Teg,
On Mon, Jan 25, 2016 at 4:51 PM, Teg <Teg at djii.com> wrote:
> Hello Igor,
>
> Then I'd note the address of the object (make a copy of the pointer
> right as it's allocated) and then verify that the address you're
> deleting is the same as the address that was allocated. I've verify
> that the correct calling convention is being used throughout too.
Yes, pointers (addresses) are the same.
>
>
> I'd single step into the destructor and see what's actually happening to
> make it crash. I'd pay attention to the "this" pointer and see if it
> makes sense.
>
> Assuming you're using visual studio and have the source to the wrapper
> if should be easy to simply step in and see exactly what line of code
> makes it crash.
Yes, MSVC 2010 and the code is mine. ;-)
Thank you.
>
> C
>
>
> Monday, January 25, 2016, 1:00:53 PM, you wrote:
>
> IK> Hi, Teg,
>
> IK> 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.
>
> IK> Does not make a difference.
> IK> I added that function and call it from the MainFrame destructor.
>
> IK> It still crashed.
>
> IK> 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
>>>
>
>
>
> --
> Teg mailto:Teg at djii.com
>
