On Mon, Jan 25, 2016 at 8:31 AM, Teg <Teg at djii.com> wrote:
> Hello Igor,
>
> 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.
>
That's not the general case. DLLs all have the same memory spaces...
although in your next part, it may be true that if you're loading DLLs
that are linked to different runtimes they may have used different
allocators and require different deallocations... but typically (and
in programs with least issues) they will use multi-threaded shared
library runtime so they all use the same allocation functions.
> 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.
>
Are you sure you're not somehow double-freeing the sqlite handle?
Especially at close I've seen exit() end up calling atexit() methods
multiple times in some circumstances...
> 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
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
