Using Visual Studio 2022 on Windows 11 x64
Using version 4.7 - I have successfully built a sqlcipher.dll which I can load and run perfectly into another dll.
However I’d like to build and link everything into my main dll.
I have defined SQLCIPHER_OMIT_DLLMAIN since my main DLL already has a DLLMain
Everything works until I am exiting and closing the database. Then I get a crash and exception. I’m guessing it’s because sqlcipher_extra_shutdown() is not being called, but this is only a guess.
This is the stack trace
> ActiveWords.dll!sqlcipher_codec_ctx_free(codec_ctx * * iCtx) Line 111273 C
ActiveWords.dll!sqlite3FreeCodecArg(void * pCodecArg) Line 112984 C
ActiveWords.dll!sqlite3PagerClose(Pager * pPager, sqlite3 * db) Line 63933 C
ActiveWords.dll!sqlite3BtreeClose(Btree * p) Line 76222 C
ActiveWords.dll!sqlite3LeaveMutexAndCloseZombie(sqlite3 * db) Line 190860 C
ActiveWords.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 190773 C
ActiveWords.dll!sqlite3_close_v2(sqlite3 * db) Line 190817 C
ActiveWords.dll!sqlite::database::{ctor}::__l2::<lambda>(sqlite3 * ptr) Line 420 C++
[External Code]
ActiveWords.dll!CDatabaseManager::Close() Line 281 C++
ActiveWords.dll!CDatabaseManager::~CDatabaseManager() Line 36 C++
[External Code]
Hello @mtissington - I don’t believe this would be an issue related to sqlcipher_extra_shutdown(). That would normally only be called at the point that the library is released and no longer being used. This should happen after sqlite3_close_v2(), so it should be unrelated. The only way I could see there being a problem is if you were calling shutdown before close.
That said, you could certainly call sqlite3_shutdown() (which would in turn call sqlcipher_extra_shutdown() when you are exiting (e.g. from your own DllMain)
Is there anything special or different about the lifecycle on the that database handle being closed? Is it being shared across multiple CDatabaseManagers or anything?
Hello @mtissington - We have attempted to reproduce this issue with a small standalone project that compiles sqlcipher into a wrapping DLL with SQLCIPHER_OMIT_DLLMAIN defined on VS 2022. The wrapper DLL contains logic to open a connection uses it, and then close it. The DLL is then loaded from a separate executable.
We did not run into any issues with the scenario as described, everything seemed to work as intended, and there were no crashes or exceptions.
Are you still seeing this issue? If so, can you attempt to narrow down the problem to a small standalone reproduction?
Thanks for the follow up - I’m still having the issue .. will try to narrow it down.
@mtissington - sounds good, thanks. For completeness, we tested this both by statically linking the wrapping DLL with a separate libsqlite3.lib, and also by compiling the amalgamation into the DLL itself.
Out of curiosity, is your DLL and particularly the CDatabaseManager being used across multiple threads? Are you compiled with SQLITE_THREADSAFE set to 1 or 2? Are you using shared cache?
SQLITE_THREADSAFE IS SET TO 1 and yes, CDatabaseManager is used across multiple thread. Oh and compiling the amalgamation into the DLL itself.
Just in case here are the defines
HAVE_STDINT_H;
_CRT_SECURE_NO_DEPRECATE;
_CRT_SECURE_NO_WARNINGS;
_CRT_NONSTDC_NO_DEPRECATE;
_CRT_NONSTDC_NO_WARNINGS;
SQLITE_THREADSAFE=1;
SQLITE_USE_URI=1;
SQLITE_ENABLE_COLUMN_METADATA=1;
SQLITE_ENABLE_STAT4=1;
SQLITE_ENABLE_FTS5=1;
SQLITE_ENABLE_LOAD_EXTENSION=1;
SQLITE_ENABLE_RTREE=1;
SQLITE_SOUNDEX=1;
SQLITE_ENABLE_MEMORY_MANAGEMENT=1;
SQLITE_ENABLE_API_ARMOR=1;
SQLITE_ENABLE_DBSTAT_VTAB=1;
SQLITE_ENABLE_STMTVTAB=1
SQLITE_TEMP_STORE=2;
SQLITE_EXTRA_SHUTDOWN=sqlcipher_extra_shutdown;
SQLITE_EXTRA_INIT=sqlcipher_extra_init;
SQLITE_PLACEHOLDER=1;
SQLITE_HAS_CODEC=1;
SQLITE_MATH_FUNCTIONS=1;
SQLITE_ENABLE_MATH_FUNCTIONS=1;
SQLITE_PERCENTILE_EXTENSION=1;
SQLITE_TOTYPE_EXTENSION=1;
SQLITE_SHA256_EXTENSION=1;
Hello @mtissington - thanks for the list. I don’t see any obvious issues with those defines. Let me know if you can narrow down any further reproduction.