Visual c++ 本机sqlite库在使用c++/cli时崩溃

短篇小说

在编译具有通用语言运行时支持的X64平台的C++应用程序和使用其内部的SQLite库时，应用程序在SQLe3MMEReAlOLC内部崩溃，试图分配大约5GB的内存量。 如果在不支持CLR的情况下编译同一应用程序，则所需的功能将正常工作，并且不会尝试分配此内存量。我用一个带条件的断点来验证这个事实

数据库本身是一个800KB的小文件，我们正在尝试运行一个简单的select*from XYZ查询。我们在代码库中现有的sqlite 3.7.11和最新的sqlite 3.7.14中都进行了尝试

这个问题是一贯的。无论我重建应用程序或使用某些设置多少次—使用CLR支持，它都会崩溃，而不使用CLR支持，它都会工作

长话短说

我试图开发一个应用程序，它利用C++编写的现有代码库中的代码，同时也利用.NETFramework的力量。 我创建了一个C++/CLI应用程序，该应用程序与使用sqlite的现有代码相链接。我的代码不直接使用sqlite。使用SQLite的现有代码是一个本地C++库，其余的代码库依赖于此。所以我不能轻易地触摸它，因此不能简单地使用System.Data.Sqlite

---

我消除了对.NET framework的所有依赖关系，创建了一个只使用现有本机代码而不使用任何.NET framework代码的简单应用程序，并对其进行了两次编译（有CLR支持和没有CLR支持）。

最终，通过使用memsys5内存分配器编译SQLITE并将其配置为在启动时使用，问题得以解决。当它不依赖于MSVCRT内存分配，而是依赖于自己的内部分配策略时，一切都起作用了

似乎由于某种神秘的力量，CLR的存在干扰了MSVCRT的内存分配功能

---

可以找到更多信息。

哎哟。崩溃是否取决于数据库的内容？您是否尝试过使用/clr仅编译少数文件以缩小问题发生的范围？是的，我尝试使用/clr仅编译所需的文件。还是一样。关于依赖性——我想它确实在某种程度上依赖于它，但我无法隔离问题。我尝试了我们公司的许多数据库，但这种情况仍然存在。数据库本身是由公司中我无法控制的另一个部门创建的。