The short story
When compiling a C++ application for the X64 platform with Common Language Runtime support and using the native sqlite library inside it, the application crashes inside sqlite3MemRealloc, attempting to allocate a huge amount of memory (around 5GB).
When the same application is compiled without CLR support, the required functionality works and NO attempt to allocate this amount of memory is made. I put a break-point with a condition to verify this fact.
The database itself is a small 800KB file, and we are attempting to run a simple “select * from XYZ” query. Tried it both with the existing sqlite 3.7.11 that we have in our code base and the latest sqlite 3.7.14.
This problem is consistent. No matter how many times I rebuild the application or play with some settings – with CLR support it crashes, without CLR support it works.
The longer story
I was trying to develop an application that leverages code from an existing code-base written in C++ but also leverages the power of the .NET framework.
I created a C++/CLI application that linked against the existing code (that utilizes sqlite inside it). My code does not use sqlite directly. The existing code that does uses sqlite is a native C++ library that the rest of the code base depends on. So I cannot touch it easily and therefore cannot simply use System.Data.Sqlite.
I isolated this problem by removing all dependencies on the .NET framework and creating a simple application that only utilizes the existing native code without using any .NET framework code, and compiling it twice – with and without CLR support.
Eventually, the problem was solved by compiling SQLITE with the memsys5 memory allocator and configuring it to use it on startup. When it did not depend on the MSVCRT memory allocation but on its own internal allocation strategy, everything worked.
It seems that by some mysterious force, the existance of the CLR inteferes with MSVCRT’s memory allocation functions.
More info can be found here.