Hi, Teg,
On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot <ikorot01 at gmail.com> wrote:
> 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.
I just ran the program under the debugger step-by-step and everything
looks "normal".
All addresses are the same. and the opening db executes successfully.
The stack trace look like this:
> sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc bytes
> C
sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 726
+ 0xc bytes C
sqlite.dll!sqlite3_close(sqlite3 * db) Line 772 + 0xe bytes C
sqlite.dll!SQLiteDatabase::Disconnect(std::vector<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,std::allocator<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > > & errorMsg) Line 49 + 0xc bytes C++
dialogs.dll!DisconnectFromDb(Database * db) Line 108 + 0x13 bytes C++
docview.exe!MainFrame::~MainFrame() Line 73 + 0xf bytes C++
The DisconnectFromDb() function is a function from DLL. It calls
SQLiteDatabase::Disconnect().
Then everything is sqlite.
Any idea of what is going on?
Thank you.
>>
>> 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
>>
