[sqlite] SQLite crashing

[Igor Korot]

Hi, again,
I did recompile everything with /MDd and I did fix couple of issues.
However the crash is back and below is the (full) stack trace:

 ()
>sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc bytes  
>   C
 sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726
+ 0xc bytesC
 sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
 
sqlite.dll!SQLiteDatabase::Disconnect(std::vector,std::allocator > > & errorMsg)  Line 59 + 0xc bytesC++
 dialogs.dll!DisconnectFromDb(Database * db)  Line 118 + 0x13 bytesC++
 docview.exe!MainFrame::~MainFrame()  Line 80 + 0x12 bytesC++
 docview.exe!MainFrame::`scalar deleting destructor'()  + 0x16 bytesC++
 docview.exe!wxAppConsoleBase::DeletePendingObjects()  Line 637 +
0x23 bytesC++
 docview.exe!wxAppConsoleBase::ProcessIdle()  Line 445C++
 docview.exe!wxAppBase::ProcessIdle()  Line 373 + 0x8 bytesC++
 docview.exe!wxEventLoopBase::ProcessIdle()  Line 98 + 0x23 bytesC++
 docview.exe!wxEventLoopManual::DoRun()  Line 263 + 0x3b bytesC++
 docview.exe!wxEventLoopBase::Run()  Line 76 + 0xf bytesC++
 docview.exe!wxAppConsoleBase::MainLoop()  Line 380 + 0x27 bytesC++
 docview.exe!wxAppConsoleBase::OnRun()  Line 301 + 0x12 bytesC++
 docview.exe!wxAppBase::OnRun()  Line 312C++
 docview.exe!wxEntryReal(int & argc, wchar_t * * argv)  Line 503 +
0x1d bytesC++
 docview.exe!wxEntry(int & argc, wchar_t * * argv)  Line 181 + 0xd
bytesC++
 docview.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
__formal, HINSTANCE__ * __formal, int nCmdShow)  Line 289 + 0x10 bytes
   C++
 docview.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
hPrevInstance, char * __formal, int nCmdShow)  Line 76 + 0x16 bytes
C++
 docview.exe!__tmainCRTStartup()  Line 547 + 0x2c bytesC
 docview.exe!WinMainCRTStartup()  Line 371C
 kernel32.dll!76f57c04()
 [Frames below may be incorrect and/or missing, no symbols loaded
for kernel32.dll]
 ntdll.dll!771aad6f()
 ntdll.dll!771aad3a()

The weird thing is that if I put the Disconnect() call in another
function, it works OK - no crash.
Only when I exit the application.

MSVC 2012 shows that the crash happens on following line:

SQLITE_API void SQLITE_STDCALL sqlite3_mutex_enter(sqlite3_mutex *p){
  if( p ){
assert( sqlite3GlobalConfig.mutex.xMutexEnter );   <--- here
sqlite3GlobalConfig.mutex.xMutexEnter(p);
  }

I'm running on Windows 8.1. SQLite is compiled into my application and
the source is from couple of days ago.

What are the conditions when the application will not be able to
acquire the global file lock?

Thank you.

On Sun, Jan 31, 2016 at 1:11 PM, Olivier Mascia  wrote:
>> Le 31 janv. 2016 ? 18:06, Igor Korot  a ?crit :
>>
>> Ok, I did try to recompile everything with /MDd.
>> The crash again happens only on the main frame destruction.
>> Everything worked after the pointer had been assigned to the main frame 
>> member.
>> I don't understand this at all.
>>
>> Thank you.
>
> Looking at the stack trace you posted, it is not SQLite code which crash, but 
> some C++ code (which happen to be inside a dll named 'sqlite.dll') probably 
> wrapping SQLite3 code itself.  It tries to delete some data, and some 
> integrity checks reveal the pointer is invalid, by that time at least.
>
>> Here is the stack trace of the crash:
>> ntdll.dll!77b973a6()
>> [Frames below may be incorrect and/or missing, no symbols loaded
>> for ntdll.dll]
>> ntdll.dll!77b5164f()
>> ntdll.dll!77b20f01()
>> KernelBase.dll!762b2844()
>>>   sqlite.dll!_CrtIsValidHeapPointer(const void * pUserData)  Line 2036
>>> C++
>> sqlite.dll!_free_dbg_nolock(void * pUserData, int nBlockUse)
>> Line 1322 + 0x9 bytesC++
>> sqlite.dll!_free_dbg(void * pUserData, int nBlockUse)  Line 1265
>> + 0xd bytesC++
>> sqlite.dll!operator delete(void * pUserData)  Line 54 + 0x10 bytesC++
>> sqlite.dll!SQLiteDatabase::`vector deleting destructor'()  + 0x65
>> bytesC++
>
> --
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[Olivier Mascia]

> Le 31 janv. 2016 ? 18:06, Igor Korot  a ?crit :
> 
> Ok, I did try to recompile everything with /MDd.
> The crash again happens only on the main frame destruction.
> Everything worked after the pointer had been assigned to the main frame 
> member.
> I don't understand this at all.
> 
> Thank you.

Looking at the stack trace you posted, it is not SQLite code which crash, but 
some C++ code (which happen to be inside a dll named 'sqlite.dll') probably 
wrapping SQLite3 code itself.  It tries to delete some data, and some integrity 
checks reveal the pointer is invalid, by that time at least.

> Here is the stack trace of the crash:
> ntdll.dll!77b973a6()
> [Frames below may be incorrect and/or missing, no symbols loaded
> for ntdll.dll]
> ntdll.dll!77b5164f()
> ntdll.dll!77b20f01()
> KernelBase.dll!762b2844()
>>   sqlite.dll!_CrtIsValidHeapPointer(const void * pUserData)  Line 2036C++
> sqlite.dll!_free_dbg_nolock(void * pUserData, int nBlockUse)
> Line 1322 + 0x9 bytesC++
> sqlite.dll!_free_dbg(void * pUserData, int nBlockUse)  Line 1265
> + 0xd bytesC++
> sqlite.dll!operator delete(void * pUserData)  Line 54 + 0x10 bytesC++
> sqlite.dll!SQLiteDatabase::`vector deleting destructor'()  + 0x65
> bytesC++

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om

[sqlite] SQLite crashing

[Igor Korot]

Teg,

On Sun, Jan 31, 2016 at 12:29 AM, Igor Korot  wrote:
> Teg,
>
> On Sat, Jan 30, 2016 at 1:54 PM, Teg  wrote:
>> Hello Igor,
>
> This is all compiling with /MTd.
>
>>
>> I  might set a break point in the destructor for the DB class and make
>> sure  it's not being fired before the exit crash.  Question marks on a
>> pointer  means  it's  an  invalid  pointer. The pointer to DB might be
>> incorrect  or  the  pointer  to something inside the DB class might be
>> incorrect. Sounds almost like it's getting destructed twice.
>
> No, the breakpoint is hit only once.
>
>>
>> What  happens  if  you  new  the DB class then use it, then immediately
>> delete it?  Does it still crash?
>
> Apparently yes. It still crashes.
> However, it does go thru the destructor and then crashes.
>
> Here is the stack trace of the crash:
>  ntdll.dll!77b973a6()
>  [Frames below may be incorrect and/or missing, no symbols loaded
> for ntdll.dll]
>  ntdll.dll!77b5164f()
>  ntdll.dll!77b20f01()
>  KernelBase.dll!762b2844()
>>sqlite.dll!_CrtIsValidHeapPointer(const void * pUserData)  Line 2036
>> C++
>  sqlite.dll!_free_dbg_nolock(void * pUserData, int nBlockUse)
> Line 1322 + 0x9 bytesC++
>  sqlite.dll!_free_dbg(void * pUserData, int nBlockUse)  Line 1265
> + 0xd bytesC++
>  sqlite.dll!operator delete(void * pUserData)  Line 54 + 0x10 bytesC++
>  sqlite.dll!SQLiteDatabase::`vector deleting destructor'()  + 0x65
> bytesC++
>  dialogs.dll!DatabaseType::OnConnect(wxWizardEvent & __formal)
> Line 125 + 0x3a bytesC++
>  dialogs.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler,
> void (wxEvent &)* func, wxEvent & event)  Line 657 + 0xf bytesC++
>  dialogs.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler *
> handler, wxEventFunctor & functor, wxEvent & event)  Line 669 + 0x22
> bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEventIfMatchesId(const
> wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent &
> event)  Line 1383 + 0x29 bytesC++
>  dialogs.dll!wxEvtHandler::SearchDynamicEventTable(wxEvent &
> event)  Line 1775 + 0x11 bytesC++
>  dialogs.dll!wxEvtHandler::TryHereOnly(wxEvent & event)  Line 1576
> + 0x15 bytesC++
>  dialogs.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event)  Line
> 3656 + 0x2d bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event)
> Line 1513 + 0xc bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEvent(wxEvent & event)  Line
> 1486 + 0xc bytesC++
>  dialogs.dll!wxWizard::ShowPage(wxWizardPage * page, bool
> goingForward)  Line 577 + 0x2a bytesC++
>  dialogs.dll!wxWizard::OnBackOrNext(wxCommandEvent & event)  Line
> 818 + 0x1e bytesC++
>  dialogs.dll!wxAppConsoleBase::HandleEvent(wxEvtHandler * handler,
> void (wxEvent &)* func, wxEvent & event)  Line 657 + 0xf bytesC++
>  dialogs.dll!wxAppConsoleBase::CallEventHandler(wxEvtHandler *
> handler, wxEventFunctor & functor, wxEvent & event)  Line 669 + 0x22
> bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEventIfMatchesId(const
> wxEventTableEntryBase & entry, wxEvtHandler * handler, wxEvent &
> event)  Line 1383 + 0x29 bytesC++
>  dialogs.dll!wxEventHashTable::HandleEvent(wxEvent & event,
> wxEvtHandler * self)  Line 989 + 0x11 bytesC++
>  dialogs.dll!wxEvtHandler::TryHereOnly(wxEvent & event)  Line 1580
> + 0x25 bytesC++
>  dialogs.dll!wxEvtHandler::TryBeforeAndHere(wxEvent & event)  Line
> 3656 + 0x2d bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEventLocally(wxEvent & event)
> Line 1513 + 0xc bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEvent(wxEvent & event)  Line
> 1486 + 0xc bytesC++
>  dialogs.dll!wxWindowBase::TryAfter(wxEvent & event)  Line 3456 +
> 0x1e bytesC++
>  dialogs.dll!wxEvtHandler::ProcessEvent(wxEvent & event)  Line
> 1499 + 0x13 bytesC++
>  dialogs.dll!wxEvtHandler::SafelyProcessEvent(wxEvent & event)
> Line 1604 + 0x13 bytesC++
>  dialogs.dll!wxWindowBase::HandleWindowEvent(wxEvent & event)
> Line 1543C++
>  dialogs.dll!wxControl::ProcessCommand(wxCommandEvent & event)
> Line 289C++
>  dialogs.dll!wxButton::SendClickEvent()  Line 367 + 0xc bytesC++
>  dialogs.dll!wxButton::MSWCommand(unsigned int param, unsigned
> short __formal)  Line 415 + 0x8 bytesC++
>  dialogs.dll!wxWindow::HandleCommand(unsigned short id_, unsigned
> short cmd, HWND__ * control)  Line 5169 + 0x1c bytesC++
>  dialogs.dll!wxWindow::MSWHandleMessage(long * result, unsigned
> int message, unsigned int wParam, long lParam)  Line 2905 + 0x1f bytes
>C++
>  dialogs.dll!wxWindow::MSWWindowProc(unsigned int message,
> unsigned int wParam, long lParam)  Line 3471 + 0x22 bytesC++
>  dialogs.dll!wxTopLevelWindowMSW::MSWWindowProc(unsigned int
> message, unsigned int wParam, long lParam)  Line 321 + 0x14 bytes
> C++
>  

[sqlite] SQLite crashing

[Igor Korot]

Clemens,

On Fri, Jan 29, 2016 at 3:19 AM, Clemens Ladisch  wrote:
> Igor Korot wrote:
>> 1>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
>> symbol __imp___vsnprintf referenced in function
>> _StringVPrintfWorkerA at 20
>
> Looks like a bug in the MSVC libraries:
> http://stackoverflow.com/questions/4596212/c-odbc-refuses-to-statically-link-to-libcmt-lib-under-vs2010

It looks like the solution is to add the MSVC 2008 odbccp32.lib to the project.

The trouble is - I don't know how compatible it will be with all other
libraries from MSVC 2010.
Moreover I would rather add the vsnprintf library from MSVC 2010 than
get old version of odbccp32.lib.

Is it possible to just add that library to the link command and not
old odbccp32.lib?

Thank you.

>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[Clemens Ladisch]

Igor Korot wrote:
> 1>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
> symbol __imp___vsnprintf referenced in function
> _StringVPrintfWorkerA at 20

Looks like a bug in the MSVC libraries:
http://stackoverflow.com/questions/4596212/c-odbc-refuses-to-statically-link-to-libcmt-lib-under-vs2010


Regards,
Clemens

[sqlite] SQLite crashing

[Teg]

Hello Igor,

I'm  probably  go  the  opposite direction and make sure everything is
built  /MDd or /MD.  Basically dynamic link the whole thing. It means
all of your projects need to be rebuilt using the same RTL though.

You just don't want 1/2 to be /MT and the other 1/2 to be /MD.



C

Thursday, January 28, 2016, 11:25:10 PM, you wrote:

IK> Hi, ALL,


IK> On Tue, Jan 26, 2016 at 3:08 PM, Clemens Ladisch  
wrote:
>> Igor Korot wrote:
>>>  sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc 
>>> bytesC
>>>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726 + 0xc 
>>> bytesC
>>>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>>>  sqlite.dll!SQLiteDatabase::Disconnect(...)  Line 51 + 0xc bytesC++
>>>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytes
>>> C++
>>>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>>>  docview.exe!MainFrame::`scalar deleting destructor'()  + 0x16 bytes
>>> C++
>>>  docview.exe!wxAppConsoleBase::DeletePendingObjects()  Line 637 + 0x23 
>>> bytesC++
>>>  docview.exe!wxAppConsoleBase::ProcessIdle()  Line 445C++
>>
>> This looks OK.
>>
>> Are you ever calling sqlite3_shutdown()?
>> Are you calling sqlite3_close() from more than one place, or more than once?
>> (Add logging to find out.)

IK> I tried to recompile the project with the /MTd, but I got this:

1>>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
IK> symbol __imp___vsnprintf referenced in function
IK> _StringVPrintfWorkerA at 20

IK> And here is my Linker Project Settings:

IK> 
odbccp32.lib;kernel32.lib;user32.lib;gdi32.lib;comdlg32.lib;winspool.lib;winmm.l?
IK> 
ib;shell32.lib;shlwapi.lib;comctl32.lib;ole32.lib;oleaut32.lib;uuid.lib;rpcrt4.li?
IK> b;advapi32.lib;version.lib;wsock32.lib;wininet.lib;%(AdditionalDependencies)

IK> Is there an easy way to fix this?

IK> Thank you.

>>
>>
>> Regards,
>> Clemens
>> ___
>> 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



-- 
 Tegmailto:Teg at djii.com

[sqlite] SQLite crashing

[Igor Korot]

Hi, ALL,


On Tue, Jan 26, 2016 at 3:08 PM, Clemens Ladisch  wrote:
> Igor Korot wrote:
>>  sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc 
>> bytesC
>>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726 + 0xc 
>> bytesC
>>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>>  sqlite.dll!SQLiteDatabase::Disconnect(...)  Line 51 + 0xc bytesC++
>>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytes
>> C++
>>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>>  docview.exe!MainFrame::`scalar deleting destructor'()  + 0x16 bytes
>> C++
>>  docview.exe!wxAppConsoleBase::DeletePendingObjects()  Line 637 + 0x23 
>> bytesC++
>>  docview.exe!wxAppConsoleBase::ProcessIdle()  Line 445C++
>
> This looks OK.
>
> Are you ever calling sqlite3_shutdown()?
> Are you calling sqlite3_close() from more than one place, or more than once?
> (Add logging to find out.)

I tried to recompile the project with the /MTd, but I got this:

1>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
symbol __imp___vsnprintf referenced in function
_StringVPrintfWorkerA at 20

And here is my Linker Project Settings:

odbccp32.lib;kernel32.lib;user32.lib;gdi32.lib;comdlg32.lib;winspool.lib;winmm.l?
ib;shell32.lib;shlwapi.lib;comctl32.lib;ole32.lib;oleaut32.lib;uuid.lib;rpcrt4.li?
b;advapi32.lib;version.lib;wsock32.lib;wininet.lib;%(AdditionalDependencies)

Is there an easy way to fix this?

Thank you.

>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[Clemens Ladisch]

Igor Korot wrote:
>  sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc 
> bytesC
>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726 + 0xc 
> bytesC
>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>  sqlite.dll!SQLiteDatabase::Disconnect(...)  Line 51 + 0xc bytesC++
>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytesC++
>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>  docview.exe!MainFrame::`scalar deleting destructor'()  + 0x16 bytes
> C++
>  docview.exe!wxAppConsoleBase::DeletePendingObjects()  Line 637 + 0x23 
> bytesC++
>  docview.exe!wxAppConsoleBase::ProcessIdle()  Line 445C++

This looks OK.

Are you ever calling sqlite3_shutdown()?
Are you calling sqlite3_close() from more than one place, or more than once?
(Add logging to find out.)


Regards,
Clemens

[sqlite] SQLite crashing

[Clemens Ladisch]

Igor Korot wrote:
>  sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc 
> bytesC
>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726 + 0xc 
> bytesC
>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>  sqlite.dll!SQLiteDatabase::Disconnect(...)  Line 49 + 0xc bytesC++
>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytesC++
>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++

Please show the rest of the stack trace.


Regards,
Clemens

[sqlite] SQLite crashing

[Teg]

Hello Igor,

https://msdn.microsoft.com/en-us/library/ms235460.aspx?f=255=-2147217396

This discussed in more details what I originally posted about.

>>A related problem can occur when you allocate memory (either
>>explicitly with new or malloc, or implicitly with strdup,
>>strstreambuf::str, and so on) and then pass a pointer across a DLL
>>boundary to be freed. This can cause a memory access violation or heap
>>corruption if the DLL and its users use different copies of the CRT
>>libraries.

Are you sure the DLL and the main application are built with the same
RTL?  This is almost certainly not an Sqlite problem. It's probably an
Sqlite mis-use problem.


How are you compiling the code? What run time library are you using? I
use  /MT  and /MTd for mostly static linking.  Then I "getprocaddress"
on  any DLL's I load. So, in my case each DLL has its own copy of the
RTL.I'm not clear how using /MD or /MDd impacts this.

I  don't use Sqlite the way you're trying to. I static link a copy and
the  wrapper  into  each application so there are no DLL boundaries to
contend with.


Monday, January 25, 2016, 11:30:00 PM, you wrote:

IK> Teg,

IK> On Mon, Jan 25, 2016 at 9:25 PM, Igor Korot  wrote:
>> Hi, Teg,
>>
>> On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot  wrote:
>>> Hi, Teg,
>>>
>>> On Mon, Jan 25, 2016 at 4:51 PM, Teg  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 
>>> bytesC
>>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726
>> + 0xc bytesC
>>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>>  
>> sqlite.dll!SQLiteDatabase::Disconnect(std::vector>>,std::allocator>> > > & errorMsg)  Line 49 + 0xc bytesC++
>>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytes
>> C++
>>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>>
>> The DisconnectFromDb() function is a function from DLL. It calls
>> SQLiteDatabase::Disconnect().
>> Then everything is sqlite.
>>
>> Any idea of what is going on?

IK> [code]
IK> SQLITE_API void SQLITE_STDCALL sqlite3_mutex_enter(sqlite3_mutex *p){
IK>   if( p ){
IK> assert( sqlite3GlobalConfig.mutex.xMutexEnter );// This is the
IK> line that fails
IK> sqlite3GlobalConfig.mutex.xMutexEnter(p);
IK>   }
IK> }
IK> [/code]

IK> Thank you.

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

[sqlite] SQLite crashing

[Igor Korot]

Hi, Clemens,

On Tue, Jan 26, 2016 at 7:14 AM, Clemens Ladisch  wrote:
> Igor Korot wrote:
>>  sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc 
>> bytesC
>>  sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726 + 0xc 
>> bytesC
>>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>>  sqlite.dll!SQLiteDatabase::Disconnect(...)  Line 49 + 0xc bytesC++
>>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytes
>> C++
>>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>
> Please show the rest of the stack trace.

Here is the full stack trace at the time of the crash:

 ()
>sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p)  Line 19996 + 0xc bytes  
>   C
 sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie)  Line 726
+ 0xc bytesC
 sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
 
sqlite.dll!SQLiteDatabase::Disconnect(std::vector,std::allocator > > & errorMsg)  Line 51 + 0xc bytesC++
 dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytesC++
 docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
 docview.exe!MainFrame::`scalar deleting destructor'()  + 0x16 bytesC++
 docview.exe!wxAppConsoleBase::DeletePendingObjects()  Line 637 +
0x23 bytesC++
 docview.exe!wxAppConsoleBase::ProcessIdle()  Line 445C++
 docview.exe!wxAppBase::ProcessIdle()  Line 373 + 0x8 bytesC++
 docview.exe!wxEventLoopBase::ProcessIdle()  Line 98 + 0x23 bytesC++
 docview.exe!wxEventLoopManual::DoRun()  Line 263 + 0x3b bytesC++
 docview.exe!wxEventLoopBase::Run()  Line 76 + 0xf bytesC++
 docview.exe!wxAppConsoleBase::MainLoop()  Line 380 + 0x27 bytesC++
 docview.exe!wxAppConsoleBase::OnRun()  Line 301 + 0x12 bytesC++
 docview.exe!wxAppBase::OnRun()  Line 312C++
 docview.exe!wxEntryReal(int & argc, wchar_t * * argv)  Line 503 +
0x1d bytesC++
 docview.exe!wxEntry(int & argc, wchar_t * * argv)  Line 181 + 0xd
bytesC++
 docview.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
__formal, HINSTANCE__ * __formal, int nCmdShow)  Line 289 + 0x10 bytes
   C++
 docview.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
hPrevInstance, char * __formal, int nCmdShow)  Line 75 + 0x16 bytes
C++
 docview.exe!__tmainCRTStartup()  Line 547 + 0x2c bytesC
 docview.exe!WinMainCRTStartup()  Line 371C
 kernel32.dll!75217c04()
 [Frames below may be incorrect and/or missing, no symbols loaded
for kernel32.dll]
 ntdll.dll!7761ad6f()
 ntdll.dll!7761ad3a()

Thank you.

>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[Scott Robison]

On Mon, Jan 25, 2016 at 2:44 PM, Teg  wrote:

> >>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...
>
> "newed" objects never fires the destructor unless you manually destruct
> it or use an auto-pointer even when you exit. In fact I use this as a
> method to get around destructor order issues when my applications
> exit. I essentially just abandon the "new"ed startup objects. It also
> makes applications exit faster just to abandon memory and depend on
> the OS to reclaim all the memory.
>

As you sure the objects that you failed to delete don't *require* some sort
of cleanup? Allowing the system to reclaim memory at process termination is
fine (though I can't imagine the difference being measurable in most cases
and I prefer cleaning up explicitly most of time). That being said, delete
also invokes destructors which can do far more than just return memory to
the C++ free-store.

It's not necessarily related to this precise problem, obviously, just a
warning flag that popped up in my reading.

-- 
Scott Robison

[sqlite] SQLite crashing

[Igor Korot]

Teg,

On Mon, Jan 25, 2016 at 9:25 PM, Igor Korot  wrote:
> Hi, Teg,
>
> On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot  wrote:
>> Hi, Teg,
>>
>> On Mon, Jan 25, 2016 at 4:51 PM, Teg  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 bytesC
>  sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
>  
> sqlite.dll!SQLiteDatabase::Disconnect(std::vector>,std::allocator> > > & errorMsg)  Line 49 + 0xc bytesC++
>  dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytesC++
>  docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++
>
> The DisconnectFromDb() function is a function from DLL. It calls
> SQLiteDatabase::Disconnect().
> Then everything is sqlite.
>
> Any idea of what is going on?

[code]
SQLITE_API void SQLITE_STDCALL sqlite3_mutex_enter(sqlite3_mutex *p){
  if( p ){
assert( sqlite3GlobalConfig.mutex.xMutexEnter );// This is the
line that fails
sqlite3GlobalConfig.mutex.xMutexEnter(p);
  }
}
[/code]

Thank you.

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

[sqlite] SQLite crashing

[Igor Korot]

Hi, Teg,

On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot  wrote:
> Hi, Teg,
>
> On Mon, Jan 25, 2016 at 4:51 PM, Teg  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 bytesC
 sqlite.dll!sqlite3_close(sqlite3 * db)  Line 772 + 0xe bytesC
 
sqlite.dll!SQLiteDatabase::Disconnect(std::vector,std::allocator > > & errorMsg)  Line 49 + 0xc bytesC++
 dialogs.dll!DisconnectFromDb(Database * db)  Line 108 + 0x13 bytesC++
 docview.exe!MainFrame::~MainFrame()  Line 73 + 0xf bytesC++

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

[sqlite] SQLite crashing

[Clemens Ladisch]

Igor Korot wrote:
> The DLL where SQLite pointer is alocated there is a DLLMain.

And what does it do?

> BOOL APIENTRY DLLMain()
> {
> }

Is it really empty?

> MainFrame::~MainFrame()
> {
> delete m_db;  // this is where the crash happens
> }

When exactly is this destructor called?
Can you show a stack trace?


Regards,
Clemens

[sqlite] SQLite crashing

[Igor Korot]

Hi, Teg,

On Mon, Jan 25, 2016 at 4:51 PM, Teg  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  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  
>>> 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 

[sqlite] SQLite crashing

[Teg]

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

[sqlite] SQLite crashing

[Teg]

Hello J,

I don't typically use "new" in my C++ applications other than in
startup to allocate things that last the life of the application.  So, I
don't have any issues with double-freeing. I never manually "new"
objects after startup. Instead I use containers to contains my objects
and leave the allocation and de-allocation to them.


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

"newed" objects never fires the destructor unless you manually destruct
it or use an auto-pointer even when you exit. In fact I use this as a
method to get around destructor order issues when my applications
exit. I essentially just abandon the "new"ed startup objects. It also
makes applications exit faster just to abandon memory and depend on
the OS to reclaim all the memory.

[sqlite] SQLite crashing

[Igor Korot]

Hi, Adam,

On Mon, Jan 25, 2016 at 2:46 PM, Adam Devita  wrote:
> Hi Igor,
> I don't think you understood what I was trying to get at.  Please
> allow me to rephrase:  There isn't enough information about how things
> are being cleaned up to point out a problem, only make general
> suggestions about good practice.
>
> This is why I was asking about where you would ensure you are properly
> shutting down the database before deleting your wrapper.  I had
> expected to see something of the form:
>
>
> //private: sqlite3 *db;
> BOOL SomeWrapperClass::Closedb()
> {
> if(db==NULL){
> b_sqlite_db_open = false;//Ensure state variable of wrapper is correct
> return TRUE; // db wasn't open, so Closed is OK
> }
>
> int ret=sqlite3_close(db);
> if (ret==SQLITE_OK){
> db = NULL;
> b_sqlite_db_open = false;
> return TRUE;  //properly closed my db connection, no errors
> }
> return FALSE; //if we got here, there is an error; break-point hit
> ; What didn't get finalized? How did this happen?
> }
>
> I would have expect you to, before delete m_db to do something like
> if(m_db != NULL) {
>   if(!m_db->Closedb() ){ //assumes that queries have already been
> finalized ;
>   ;//error handle code, break point, how did we fail to close?
>}
> delete m_db;
>  }
>
> or a method of your dll that is some exported DestroyObject(Database *db) ;
>
> or at least tell us that you are ensuring sqlite_close is called via
> the destructor of m_db;

Yes, sqlite3_close() _is_ called from the m_db destructor.
Moreover, for now I am just opening the db thru the loading the DLL
dynamically and
calling the DLL function which creates an object and connects to the db:

SQLiteDatabase::SQLiteDatabase()
{
}

SQLiteDatabase::~SQLiteDatabase()
{
sqlite3_close();
}

int SQLiteDatabase::Connect()
{
int result = sqlite3_open();
if( result != SQLITE_OK )
{
// handling error
}
}

In the MainFrame:

void MainFrame::ConnectToDb()
{
Database *db = NULL;
LoadLibrary();
func = GetProcAddress( "CreateObject" );
m_db = func( db );
}

In the DLL:

extern "C" __declspec(dllexport) Database *CreateObject(Database *db)
{
db = new SQLiteDatabase();
int res = db->Connect();
if( res )
delete db;
return db;
}

and then exiting the main application, i.e. closing the connection.
No queries are issued for the database.

Moreover all pointers are the same: from the point I call new in DLL'
CreateObject(), then
in ConnectToDB() in MainFrame' ConnectToDb() function and finally in
the MainFrame' destructor.

Also it does not matter whether I'm trying to do "delete m_db" in the
MainFrame destructor or try to
close the connection from an additional exported function - it still crashes.

Thank you.

>
> While in C++ one may choose to not check if the thing being deleted is
> NULL before doing it, it is a clutter/style thing. For debugging
> purposes  finding out that the thing that should have been null isn't
> as expected.  It can often lead to one saying "hey, that should have
> got deleted already!... oh somehow  delete x instead of safe_delete(x)
> got used so while it got deleted earlier and x should have been null
> at this point"
>
> Are you unit testing the trivial cases?
> Create+Destroy
> Create+Connect+Destroy
> Create+Connect+DoBasicQuery+Destroy
>
>
> regards,
> Adam
>
> On Mon, Jan 25, 2016 at 2:02 PM, Igor Korot  wrote:
>> Hi, Adam,
>>
>> On Mon, Jan 25, 2016 at 11:27 AM, Adam Devita  
>> 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  wrote:
 Hi, Peter,

 On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  
 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 

[sqlite] SQLite crashing

[Adam Devita]

Hi Igor,
I don't think you understood what I was trying to get at.  Please
allow me to rephrase:  There isn't enough information about how things
are being cleaned up to point out a problem, only make general
suggestions about good practice.

This is why I was asking about where you would ensure you are properly
shutting down the database before deleting your wrapper.  I had
expected to see something of the form:


//private: sqlite3 *db;
BOOL SomeWrapperClass::Closedb()
{
if(db==NULL){
b_sqlite_db_open = false;//Ensure state variable of wrapper is correct
return TRUE; // db wasn't open, so Closed is OK
}

int ret=sqlite3_close(db);
if (ret==SQLITE_OK){
db = NULL;
b_sqlite_db_open = false;
return TRUE;  //properly closed my db connection, no errors
}
return FALSE; //if we got here, there is an error; break-point hit
; What didn't get finalized? How did this happen?
}

I would have expect you to, before delete m_db to do something like
if(m_db != NULL) {
  if(!m_db->Closedb() ){ //assumes that queries have already been
finalized ;
  ;//error handle code, break point, how did we fail to close?
   }
delete m_db;
 }

or a method of your dll that is some exported DestroyObject(Database *db) ;

or at least tell us that you are ensuring sqlite_close is called via
the destructor of m_db;

While in C++ one may choose to not check if the thing being deleted is
NULL before doing it, it is a clutter/style thing. For debugging
purposes  finding out that the thing that should have been null isn't
as expected.  It can often lead to one saying "hey, that should have
got deleted already!... oh somehow  delete x instead of safe_delete(x)
got used so while it got deleted earlier and x should have been null
at this point"

Are you unit testing the trivial cases?
Create+Destroy
Create+Connect+Destroy
Create+Connect+DoBasicQuery+Destroy


regards,
Adam

On Mon, Jan 25, 2016 at 2:02 PM, Igor Korot  wrote:
> Hi, Adam,
>
> On Mon, Jan 25, 2016 at 11:27 AM, Adam Devita  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  wrote:
>>> Hi, Peter,
>>>
>>> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  
>>> 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 

[sqlite] SQLite crashing

[Igor Korot]

Hi, Adam,

On Mon, Jan 25, 2016 at 11:27 AM, Adam Devita  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  wrote:
>> Hi, Peter,
>>
>> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  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

[sqlite] SQLite crashing

[Igor Korot]

Hi, Peter,

On Mon, Jan 25, 2016 at 11:37 AM, Peter Aronson  wrote:
> How are you building the DLL and the executable?  Are they both including a
> copy of sqlite3.obj?  Or are you using a sqlite3.dll?

I'm building SQLite from source.
The DLL and executable both do not reference sqlite3.{obj,dll}.

They rather link to the .lib file which has all exported functions.

Thank you.

>
> Peter
>
>
> On 1/25/2016 9:16 AM, Igor Korot wrote:
>>
>> Hi, Peter,
>>
>> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  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
>>
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[Igor Korot]

Hi, Teg,

On Mon, Jan 25, 2016 at 11:31 AM, Teg  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.

Does not make a difference.
I added that function and call it from the MainFrame destructor.

It still crashed.

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  
> 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
>
>
>
> --
>  Tegmailto:Teg at djii.com
>

[sqlite] SQLite crashing

[Teg]

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.


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



-- 
 Tegmailto:Teg at djii.com

[sqlite] SQLite crashing

[Adam Devita]

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?

regards,
Adam DeVita

On Mon, Jan 25, 2016 at 11:16 AM, Igor Korot  wrote:
> Hi, Peter,
>
> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  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] SQLite crashing

[Igor Korot]

Hi, Peter,

On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  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] SQLite crashing

[Igor Korot]

Hi, Clemens,

On Mon, Jan 25, 2016 at 2:42 AM, Clemens Ladisch  wrote:
> Igor Korot wrote:
>> Upon exiting from the application
>
> When exactly?  Is DllMain() involved in any way?

The DLL where SQLite pointer is alocated there is a DLLMain.
Then this pointer is brought back to the main application
(wxWidgets-based). At this
point the DLL is unloaded.
When I close the main frame I am trying to disconnect from the
database and delete
the pointer. But the crash occur when disconnecting.

Thank you.

>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing

[J Decker]

On Mon, Jan 25, 2016 at 8:31 AM, Teg  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  
> 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
>
>
>
> 

[sqlite] SQLite crashing

[Peter Aronson]

How are you building the DLL and the executable?  Are they both 
including a copy of sqlite3.obj?  Or are you using a sqlite3.dll?

Peter

On 1/25/2016 9:16 AM, Igor Korot wrote:
> Hi, Peter,
>
> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson  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
>

[sqlite] SQLite crashing

[Peter Aronson]

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.

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] SQLite crashing

[Clemens Ladisch]

Igor Korot wrote:
> Upon exiting from the application

When exactly?  Is DllMain() involved in any way?


Regards,
Clemens

[sqlite] SQLite crashing

[Igor Korot]

If it matters, I'm trying Win 8.1 with MSVC 2010.

Thank you.

On Mon, Jan 25, 2016 at 12:18 AM, 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] SQLite crashing

[Igor Korot]

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.

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[Shane Harrelson]

Version 3.6.13 fixed some potential alignment issues that could occur on
SPARC (and potentially other) architectures.  I don't know how you or Apple
are testing your app, but if you (or they) are using a device emulator for
the testing, the emulator might not be testing alignment conditions the
same.

HTH.
-Shane

On Tue, Apr 21, 2009 at 11:27 AM, D. Richard Hipp  wrote:

>
> On Apr 21, 2009, at 11:10 AM, Mark Spiegel wrote:
>
> > I'm a bit confused by the following:
> >
> > "The assign 100K or so to each database connection's lookaside memory
> > allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...)
> > immediately after it is opened."
> >
> > If memory is at a premium, why would you reserve a large amount of it
> > for SQLite's "look aside allocator"?  (It's really a zone allocator.)
> > This SQLite mechanism ostensibly attempts to trade memory for
> > speed.  If
> > memory is at a premium, in this case a fixed upper bound, that trade
> > off
> > doesn't seem to make sense.  I would think in a case where memory is
> > tight, zero bytes should be reserved.
> >
>
> This is a reasonable observation.
>
> On the other hand, the lookaside memory allocator (which is just a
> zone allocator, as you observe) makes a big performance difference.
> And if you only have a single database connection, it doesn't really
> matter if the memory goes into lookaside or is in the global heap.  If
> you have multiple database connections, you might get increased memory
> efficiency by sharing between those two connections - which cannot
> happen with lookaside.
>
> The page cache is going to be the biggest user of memory.  The page
> cache memory will probably be measured in megabytes.  Memory used by
> lookaside is measured in kilobytes.  A few dozen KB of additional
> memory assigned to lookaside won't make that much difference in your
> overall memory usage, but it will make a difference in performance.
> So it seems to me to be worth the tradeoff, even if memory is tight.
>
> The reason I suggested using sqltie3_db_config() to assign a static
> buffer for lookaside is so that the lookaside subsystem will not go to
> the heap to get its (default) 50K allocation.  The MEMSYS5 memory
> allocator is a first-fit power-of-two memory allocator specifically
> designed to avoid memory fragmentation and hence allow applications to
> be designed that are guaranteed to never fail a memory allocation.
> But doing large heap allocations (more than 2K or 4K) tends to defeat
> the anti-fragmentation properties of MEMSYS5.   Hence, we desire to
> avoid the 50K heap allocation for the initial lookaside buffer.  One
> could, as you observe, achieve the same result by turning lookaside
> off all together, but then you take a performance hit.
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[D. Richard Hipp]

On Apr 21, 2009, at 11:10 AM, Mark Spiegel wrote:

> I'm a bit confused by the following:
>
> "The assign 100K or so to each database connection's lookaside memory
> allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...)
> immediately after it is opened."
>
> If memory is at a premium, why would you reserve a large amount of it
> for SQLite's "look aside allocator"?  (It's really a zone allocator.)
> This SQLite mechanism ostensibly attempts to trade memory for  
> speed.  If
> memory is at a premium, in this case a fixed upper bound, that trade  
> off
> doesn't seem to make sense.  I would think in a case where memory is
> tight, zero bytes should be reserved.
>

This is a reasonable observation.

On the other hand, the lookaside memory allocator (which is just a  
zone allocator, as you observe) makes a big performance difference.   
And if you only have a single database connection, it doesn't really  
matter if the memory goes into lookaside or is in the global heap.  If  
you have multiple database connections, you might get increased memory  
efficiency by sharing between those two connections - which cannot  
happen with lookaside.

The page cache is going to be the biggest user of memory.  The page  
cache memory will probably be measured in megabytes.  Memory used by  
lookaside is measured in kilobytes.  A few dozen KB of additional  
memory assigned to lookaside won't make that much difference in your  
overall memory usage, but it will make a difference in performance.   
So it seems to me to be worth the tradeoff, even if memory is tight.

The reason I suggested using sqltie3_db_config() to assign a static  
buffer for lookaside is so that the lookaside subsystem will not go to  
the heap to get its (default) 50K allocation.  The MEMSYS5 memory  
allocator is a first-fit power-of-two memory allocator specifically  
designed to avoid memory fragmentation and hence allow applications to  
be designed that are guaranteed to never fail a memory allocation.   
But doing large heap allocations (more than 2K or 4K) tends to defeat  
the anti-fragmentation properties of MEMSYS5.   Hence, we desire to  
avoid the 50K heap allocation for the initial lookaside buffer.  One  
could, as you observe, achieve the same result by turning lookaside  
off all together, but then you take a performance hit.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[Mark Spiegel]

I'm a bit confused by the following:

"The assign 100K or so to each database connection's lookaside memory 
allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) 
immediately after it is opened."

If memory is at a premium, why would you reserve a large amount of it 
for SQLite's "look aside allocator"?  (It's really a zone allocator.)  
This SQLite mechanism ostensibly attempts to trade memory for speed.  If 
memory is at a premium, in this case a fixed upper bound, that trade off 
doesn't seem to make sense.  I would think in a case where memory is 
tight, zero bytes should be reserved.

Jason Boehle wrote:
 I have written an application for the iPhone called Grocery iQ that
 uses SQLite.  I don't link to or use the built-in SQLite library on
 the iPhone.  Instead, I compile the SQLite amalgamation into the
 executable.  The SQLite version currently being used in our app is
 3.6.7.
 
>>> I sent instructions to Brian Killen on how you can download the latest
>>> version of SQLite+CEROD.  Perhaps recompiling will help.
>>>   
>
> Are there any particular bug fixes or changes that you know of that
> might address my problem?  I'm all for upgrading the SQLite version,
> it's just that we will have to do several days of testing to verify it
> works well, resubmit to Apple, then wait 5+ days to hear from them if
> it works or not.  Although given their tech support response times, we
> may have all of that done before I ever hear back from them.
>
>   
 * before opening the database, the only other SQLite API calls are:
   sqlite3_config(SQLITE_CONFIG_HEAP, [0], 3145728,
 512); // mSqliteMemory is declared as: unsigned char
 mSqliteMemory[3145728];
 
>>> You will probably do better to allocate most of that 3MB to page cache
>>> using sqlite3_config(SQLITE_CONFIG_PAGECHACHE, ...).  The assign 100K
>>> or so to each database connection's lookaside memory allocator using
>>> sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it
>>> is opened.  With the above, usually a 100K or so is enough heap,
>>> though more might be required if you are holding many prepared
>>> statements or if you are using unusually big prepared statements.
>>>
>>> Oops.  I'm late for meeting.  More to follow later tonight.
>>>   
>> As I was saying
>>
>> Use sqlite3_status() to actually measure your memory usage.  Make
>> adjustments once you know how the memory is being used.  Don't guess;
>> measure. Also remember that later versions of SQLite use less memory
>> for storing prepared statements, so you might want to upgrade if
>> memory is an issue.  Limit your cache sizes using the cache_size
>> pragma.  Make use of sqlite3_soft_heap_limit() if you need to.  Or
>> right a custom pcache implementation that limits the amount of memory
>> used for the page cache.
>> 
>
> Thank you for the tips on tuning the memory usage.  I will definitely
> use this advice when working on Grocery iQ 2.0.  The way I have it
> working now though, I shouldn't be experiencing any problems like
> Apple has reported, right?  If SQLite fails any allocations, it should
> return an error and fail gracefully, correct?
>
> -Jason
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>   
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[Jason Boehle]

>>> I have written an application for the iPhone called Grocery iQ that
>>> uses SQLite.  I don't link to or use the built-in SQLite library on
>>> the iPhone.  Instead, I compile the SQLite amalgamation into the
>>> executable.  The SQLite version currently being used in our app is
>>> 3.6.7.
>>
>> I sent instructions to Brian Killen on how you can download the latest
>> version of SQLite+CEROD.  Perhaps recompiling will help.

Are there any particular bug fixes or changes that you know of that
might address my problem?  I'm all for upgrading the SQLite version,
it's just that we will have to do several days of testing to verify it
works well, resubmit to Apple, then wait 5+ days to hear from them if
it works or not.  Although given their tech support response times, we
may have all of that done before I ever hear back from them.

>>> * before opening the database, the only other SQLite API calls are:
>>>       sqlite3_config(SQLITE_CONFIG_HEAP, [0], 3145728,
>>> 512); // mSqliteMemory is declared as: unsigned char
>>> mSqliteMemory[3145728];
>>
>> You will probably do better to allocate most of that 3MB to page cache
>> using sqlite3_config(SQLITE_CONFIG_PAGECHACHE, ...).  The assign 100K
>> or so to each database connection's lookaside memory allocator using
>> sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it
>> is opened.  With the above, usually a 100K or so is enough heap,
>> though more might be required if you are holding many prepared
>> statements or if you are using unusually big prepared statements.
>>
>> Oops.  I'm late for meeting.  More to follow later tonight.
>
>
> As I was saying
>
> Use sqlite3_status() to actually measure your memory usage.  Make
> adjustments once you know how the memory is being used.  Don't guess;
> measure. Also remember that later versions of SQLite use less memory
> for storing prepared statements, so you might want to upgrade if
> memory is an issue.  Limit your cache sizes using the cache_size
> pragma.  Make use of sqlite3_soft_heap_limit() if you need to.  Or
> right a custom pcache implementation that limits the amount of memory
> used for the page cache.

Thank you for the tips on tuning the memory usage.  I will definitely
use this advice when working on Grocery iQ 2.0.  The way I have it
working now though, I shouldn't be experiencing any problems like
Apple has reported, right?  If SQLite fails any allocations, it should
return an error and fail gracefully, correct?

-Jason
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[D. Richard Hipp]

On Apr 20, 2009, at 6:09 PM, D. Richard Hipp wrote:

>
> On Apr 20, 2009, at 5:32 PM, Jason Boehle wrote:
>
>> I have written an application for the iPhone called Grocery iQ that
>> uses SQLite.  I don't link to or use the built-in SQLite library on
>> the iPhone.  Instead, I compile the SQLite amalgamation into the
>> executable.  The SQLite version currently being used in our app is
>> 3.6.7.
>
> I sent instructions to Brian Killen on how you can download the latest
> version of SQLite+CEROD.  Perhaps recompiling will help.
>
>> * before opening the database, the only other SQLite API calls are:
>>   sqlite3_config(SQLITE_CONFIG_HEAP, [0], 3145728,
>> 512); // mSqliteMemory is declared as: unsigned char
>> mSqliteMemory[3145728];
>
> You will probably do better to allocate most of that 3MB to page cache
> using sqlite3_config(SQLITE_CONFIG_PAGECHACHE, ...).  The assign 100K
> or so to each database connection's lookaside memory allocator using
> sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it
> is opened.  With the above, usually a 100K or so is enough heap,
> though more might be required if you are holding many prepared
> statements or if you are using unusually big prepared statements.
>
> Oops.  I'm late for meeting.  More to follow later tonight.


As I was saying

Use sqlite3_status() to actually measure your memory usage.  Make  
adjustments once you know how the memory is being used.  Don't guess;  
measure. Also remember that later versions of SQLite use less memory  
for storing prepared statements, so you might want to upgrade if  
memory is an issue.  Limit your cache sizes using the cache_size  
pragma.  Make use of sqlite3_soft_heap_limit() if you need to.  Or  
right a custom pcache implementation that limits the amount of memory  
used for the page cache.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite crashing on iPhone (or so says Apple)

[D. Richard Hipp]

On Apr 20, 2009, at 5:32 PM, Jason Boehle wrote:

> I have written an application for the iPhone called Grocery iQ that
> uses SQLite.  I don't link to or use the built-in SQLite library on
> the iPhone.  Instead, I compile the SQLite amalgamation into the
> executable.  The SQLite version currently being used in our app is
> 3.6.7.

I sent instructions to Brian Killen on how you can download the latest  
version of SQLite+CEROD.  Perhaps recompiling will help.

> * before opening the database, the only other SQLite API calls are:
>sqlite3_config(SQLITE_CONFIG_HEAP, [0], 3145728,
> 512); // mSqliteMemory is declared as: unsigned char
> mSqliteMemory[3145728];

You will probably do better to allocate most of that 3MB to page cache  
using sqlite3_config(SQLITE_CONFIG_PAGECHACHE, ...).  The assign 100K  
or so to each database connection's lookaside memory allocator using  
sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it  
is opened.  With the above, usually a 100K or so is enough heap,  
though more might be required if you are holding many prepared  
statements or if you are using unusually big prepared statements.

Oops.  I'm late for meeting.  More to follow later tonight.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite crashing on iPhone (or so says Apple)

[Jason Boehle]

I have written an application for the iPhone called Grocery iQ that
uses SQLite.  I don't link to or use the built-in SQLite library on
the iPhone.  Instead, I compile the SQLite amalgamation into the
executable.  The SQLite version currently being used in our app is
3.6.7.

We have been working hard on a new update for our application, which
we first submitted to Apple about 3 weeks ago.  They rejected our
update because they said it crashes on startup.  However, in our
testing (100+ hours of QA on 15+ different devices), we have never
once seen the app crash like they are claiming.

Hoping that maybe our first submission was just an incorrectly signed
executable or a corrupt upload, I rebuilt and resubmitted the app.  It
got rejected again for the same reason.

Apple sent us crash logs, which show it crashing deep in SQLite code.
However, the crash is at an odd place.  We still cannot reproduce this
crash locally, so I'm reaching out for some help on this issue.

The crash logs are all the same, here is the stack trace:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000d
Crashed Thread:  0

Thread 0 Crashed:
0   Grocery iQ        0x0002d006 sqlite3ExprCodeTarget
(sqlite3.c:57600)
1   Grocery iQ        0x0002d648 sqlite3ExprCodeTemp
(sqlite3.c:57879)
2   Grocery iQ        0x0002cde4 sqlite3ExprCodeTarget
(sqlite3.c:57493)
3   Grocery iQ        0x0002d648 sqlite3ExprCodeTemp
(sqlite3.c:57879)
4   Grocery iQ        0x0002cde4 sqlite3ExprCodeTarget
(sqlite3.c:57493)
5   Grocery iQ        0x0002d648 sqlite3ExprCodeTemp
(sqlite3.c:57879)
6   Grocery iQ        0x0002cde4 sqlite3ExprCodeTarget
(sqlite3.c:57493)
7   Grocery iQ        0x0002dade sqlite3ExprCode
(sqlite3.c:57894)
8   Grocery iQ        0x00042ef0 sqlite3Update (sqlite3.c:77390)
9   Grocery iQ        0x000447de sqlite3Parser (sqlite3.c:84117)
10  Grocery iQ        0x00045f7a sqlite3RunParser
(sqlite3.c:85471)
11  Grocery iQ        0x000464fa sqlite3NestedParse
(sqlite3.c:60739)
12  Grocery iQ        0x00048370
sqlite3AlterFinishAddColumn (sqlite3.c:59173)
13  Grocery iQ        0x00045b16 sqlite3Parser (sqlite3.c:84603)
14  Grocery iQ        0x00045f7a sqlite3RunParser
(sqlite3.c:85471)
15  Grocery iQ        0x000487ee sqlite3LockAndPrepare
(sqlite3.c:71412)
16  Grocery iQ        0x0003c41e sqlite3_exec (sqlite3.c:71549)
17  Grocery iQ        0xce44 -[SQLDatabase
execQuery:] (SQLDatabase.m:122)
18  Grocery iQ        0x2c42
-[GroceryIQAppDelegate upgradeSchema2To3] (GroceryIQAppDelegate.m:281)
19  Grocery iQ        0x3218
-[GroceryIQAppDelegate upgradeSchemaToLatestVersion]
(GroceryIQAppDelegate.m:377)
20  Grocery iQ        0x3600
-[GroceryIQAppDelegate ensureDatabases] (GroceryIQAppDelegate.m:442)
21  Grocery iQ        0x2250
-[GroceryIQAppDelegate initApp] (GroceryIQAppDelegate.m:68)
22  Grocery iQ        0x26b8
-[GroceryIQAppDelegate applicationDidFinishLaunching:]
(GroceryIQAppDelegate.m:143)
23  UIKit     0x30a4ef24 -[UIApplication
performInitializationWithURL:asPanel:] + 160
24  UIKit     0x30a57dec -[UIApplication
_runWithURL:] + 644
25  Foundation        0x306945a2 __NSFireDelayedPerform + 326
26  CoreFoundation        0x30269d88 CFRunLoopRunSpecific + 2642
27  CoreFoundation        0x30269320 CFRunLoopRunInMode + 44
28  GraphicsServices      0x31567e58 GSEventRunModal + 268
29  UIKit     0x30a4fa6c -[UIApplication _run] + 520
30  UIKit     0x30a591d0 UIApplicationMain + 1132
31  Grocery iQ        0x2090 main (main.m:6)
32  Grocery iQ        0x202c start + 44

The SQL statement it is crashing on is an ALTER TABLE command:

ALTER TABLE listitems ADD COLUMN 'storeid' INTEGER DEFAULT NULL

Before this statement, the app has already successfully executed
several SQL statements that create and populate other tables.  The
listitems table already exists at the time of the ALTER TABLE
execution.
It is the first ALTER TABLE statement executed against the database.

Other important details about our application:

* we have licensed the CEROD extension for SQLite and it, too, is
compiled into our app.  It's capabilities are not used for this
database, though.
* the database is created with the following call:
sqlite3_open_v2([mPath fileSystemRepresentation], ,
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, nil);
* there is only one connection open to the database
* before opening the database, the only other SQLite API calls are: