使用 .NET 中的 VCL (C++Builder) DLL 时发生资源泄漏
我有一个用 C++Builder (2006) 编写的 DLL，并且我从 .NET 应用程序调用 DLL 中的单个函数。
问题是，当我关闭 .NET 应用程序（并且 DLL 与其分离）时，我收到 CodeGuard 错误，指出它检测到资源泄漏（并且我在 CodeGuard 日志文件中看到泄漏）。当释放 DLL 时，我还看到 Visual Studio 中弹出 LoaderLock MDA（可能是出于同样的原因？）。
现在，我 99% 确定我正在释放 DLL 函数中使用的所有内存。事实上，我尝试使用同名函数构建一个虚拟 DLL，该函数完全不执行任何操作，但当从 .NET 应用程序卸载该 DLL 时，仍然会出现资源泄漏问题。
此时我唯一怀疑的是我正在使用 DLL 中内置的 VCL。从 DLL 分离时是否需要显式调用一些未初始化函数？可能发生什么事？
ps CodeGuard 日志文件中给出的调用堆栈中的内存地址似乎远远超出了我在 Map 文件中看到的任何内容。
I have a DLL that's written in C++Builder (2006), and I'm invoking a single function in the DLL from a .NET application.
The problem is, when I close the .NET application (and the DLL gets detached from it) I get a CodeGuard error saying that it detected resource leaks (and I see the leaks in the CodeGuard log file). I also see the LoaderLock MDA pop up in Visual Studio when freeing the DLL (probably for the same reason?).
Now, I'm 99% certain that I'm freeing all the memory I'm using in the DLL function. In fact, I tried building a dummy DLL with an identically-named function that does absolutely nothing, and still got resource leaks when the DLL is unloaded from the .NET application.
My only suspicion at this point is the fact that I'm using VCL built into the DLL. Is there some uninitialization function that I need to call explicitly when detaching from the DLL? What could be going on?
p.s. The memory addresses from the call stack given in the CodeGuard log file seem to be well beyond anything I see in my Map file.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这听起来对我在 Delphi 中追寻一段时间的一个问题非常熟悉。我不久前问了这个问题。我至少部分追踪到了未释放的
threadvar（线程本地存储）内存。我相信C++Builder使用与Delphi相同的VCL组件，所以这可能是同样的问题。不幸的是，除了将来再次加载 DLL 时不卸载之外，我没有找到任何令人满意的解决方案。This sounds extremely familiar to an issue I chased for a while with Delphi. I asked the question on SO some while back. I tracked it down at least partially to
threadvar(thread local storage) memory that is not freed. I believe that C++Builder uses the same VCL components as Delphi, so it could be the same issue. Unfortunately, I did not find any satisfactory solution other than to not unload the DLL if it was ever going to be loaded again in the future.