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.
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.
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
