Hi, Adam,
On Mon, Jan 25, 2016 at 11:27 AM, Adam Devita <adevita at verifeye.com> wrote:
> Where do you pass to the dll something that goes to sqlite3_close(db); ?
> ( https://www.sqlite.org/c3ref/close.html )
> When that happens, does m_db get set to NULL (or now refers to memory
> that is now NULL)
> Do you check for m_db == NULL before deleting it?
SQLiteDatabase class is just a wrapper around the SQLite interface.
The constructor is empty, but in the Connect() function of the class I call
sqlite3_open().
And here is the code that you are asking for:
void MainFrame::ConnectToDb()
{
Database *db = NULL;
LoadLibrary();
func = GetProcAddress();
m_db = func( db );
}
Also, in C++ delete'ing NULL is perfectly normal operation.
Thank you.
>
> regards,
> Adam DeVita
>
> On Mon, Jan 25, 2016 at 11:16 AM, Igor Korot <ikorot01 at gmail.com> wrote:
>> Hi, Peter,
>>
>> 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.
>>
>> The SQLite is built only once and with just one version of the code.
>>
>> Consider following pseudo-code:
>>
>> In DLL:
>>
>> BOOL APIENTRY DLLMain()
>> {
>> }
>>
>> extern "C" __declspec(dllexport) Database *CreateObject(Database *db)
>> {
>> db = new SQLiteDatabase();
>> db->Connect();
>> return db;
>> }
>>
>> In the main application:
>>
>> mainframe.h:
>>
>> class MainFrame
>> {
>> public:
>> MainFrame();
>> ~MainFrame();
>> void ConnectToDb();
>> private:
>> Database *m_db;
>> };
>>
>> mainframe.cpp:
>>
>> void MainFrame::ConnectToDb()
>> {
>> Database *db = NULL;
>> LoadLibrary();
>> func = GetProcAddress();
>> m_db = func( db );
>> }
>>
>> MainFrame::~MainFrame()
>> {
>> delete m_db; // this is where the crash happens
>> }
>>
>> The pointer address are the same in DLL and main application MainFrame class.
>> And as I said the crash occurs when it tries to acquire the mutex lock.
>>
>> 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
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> --
> --------------
> VerifEye Technologies Inc.
> 151 Whitehall Dr. Unit 2
> Markham, ON
> L3R 9T1
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
