使用 DLL 代码时堆损坏

发布于 2024-12-09 02:23:47 字数 559 浏览 0 评论 0原文

我有一些代码需要放入公共库 dll 中。这段代码是一个 CalibrationFileData 类,当它作为当前项目的一部分构建时,工作得非常好。但是,如果 CalibrationFileData 构建在公共库中,则程序会崩溃,并出现堆损坏。

我已确保所有分配和释放都发生在类内,并使用适当的访问器等。但是,问题不会消失。为了以防万一,我有时会传递成对的向量,绝对不是普通的旧数据,但向量操作仅通过访问器发生,因此不应该在模块之间发生任何分配。

我缺少什么吗?

编辑:向量如下:

std::vector<std::pair<CvPoint2D32f, CvPoint3D32f>>* extrinsicCorrespondences;
std::vector<int>* pointsPerImage;

我不需要担心深层复制,因为它们不是堆分配的,对吗?顺便说一句,我尝试使用指向向量的指针(如上所述)来回避这个问题,但无论如何它都没有什么区别。

I have some code that I need to place in a common library dll. This code, a class CalibrationFileData, works perfectly fine when it's built as part of the current project. However, if CalibrationFileData is built in the common library, the program crashes, mentioning heap corruptions.

I have made sure that all allocations and deallocations occur within the class, with appropriate accessors, etc. Still, the problem won't go away. Just in case it makes any difference, I am sometimes passing vectors of pairs, definitely not plain old data, but the vector manipulation only occurs through the accessors, so there shouldn't be any allocation happening across modules.

Anything I'm missing?

Edit: The vectors are these:

std::vector<std::pair<CvPoint2D32f, CvPoint3D32f>>* extrinsicCorrespondences;
std::vector<int>* pointsPerImage;

I shouldn't need to worry about deep copies, since they're not heap allocated, right? Incidentally, I tried using pointers to vectors, as above, to sidestep the problem, but it didn't make a difference anyway.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

摘星┃星的人 2024-12-16 02:23:47

检查库和可执行文件之间的编译标志是否匹配。例如,在 Windows 上,确保您使用相同的 C 运行时库 (CRT)(/MD 与 /MT)。检查来自链接器的警告。

Check the compile flags match between the library and the executable. For example, on Windows ensure you're using the same C Runtime Library (CRT) (/MD vs /MT). Check for warnings from the linker.

记忆之渊 2024-12-16 02:23:47

您确定当您在方法中获得向量对象内容的所有权时,您正在将它们深度复制到实例变量中吗?

Are you certain that when you take ownership of the contents of the vector objects, within your methods, you are deep-copying them into your instance variables?

巨坚强 2024-12-16 02:23:47

你应该检查向量对象内的深层副本,我认为它与深层副本有关

you should check deep copies inside vector object,it is pertain with deepcopy i think

美煞众生 2024-12-16 02:23:47

两个项目中为 _SECURE_SCL 定义的值是否不同?

Could it be different values defined for _SECURE_SCL in the two projects ?

无声无音无过去 2024-12-16 02:23:47

您可能错过了客户端代码的某些部分,这些代码试图释放您的 DLL 分配的内存,反之亦然。

也许最简单的事情是确保客户端和 DLL 使用相同的内存分配器。不仅是同类,而且是分配器的相同实际“实例”。在 Visual C++ 上,这可以通过客户端和 DLL 使用“多线程调试 DLL (/MDd)”或“多线程 DLL (/MD)”运行时库来最轻松地实现。

It's likely you missed some piece of the client's code that tries to deallocate a memory that your DLL allocated or vice versa.

Perhaps the easiest thing to do would be to ensure that both client and the DLL use the same memory allocator. Not just the same kind, but the same actual "instance" of the allocator. On Visual C++, this is most easily achieved by both client and DLL using a "Multi-threaded Debug DLL (/MDd)" or "Multi-threaded DLL (/MD)" runtime library.

长不大的小祸害 2024-12-16 02:23:47

在 Visual Studio 的命令行选项中删除此 _SECURE_SCL。大多数情况下,此崩溃是由细节之间的 _SECURE_SCL 不匹配引起的。更多详细信息可以在这里找到:http://kmdarshan.com/blog/?p=3830

In the command line option, in visual studio remove this _SECURE_SCL. Mostly this crash is caused by _SECURE_SCL mismatch among the details. More details can be found here: http://kmdarshan.com/blog/?p=3830

安静被遗忘 2024-12-16 02:23:47

您应该区分紧耦合松散耦合DLL

紧密耦合 DLL 意味着

DLL 是使用完全相同的编译器版本、打包和构建的
调用约定设置、库选项作为应用程序,以及
两者都动态链接到运行时库(/MD 编译器选项)。
这使您可以来回传递对象,包括 STL 容器,
从应用程序内部分配DLL对象,从基类派生
其他模块中的类,尽你所能
不使用DLL。缺点是不能再
独立于主应用程序部署DLL。两者都必须是
一起建造的。 DLL 只是为了缩短进程启动时间
和工作集,因为应用程序可以在之前开始运行
加载DLL(使用/delayload链接器选项)。构建时间
也比单个模块更快,特别是当整个程序
使用优化。但优化并没有发生在整个系统中
应用程序-DLL 边界。任何不平凡的改变仍然会
需要重建两者。

如果是松散耦合 DLL,那么

导出 DLL 函数时,最好只接受整数
数据类型,即 int 或指针。

以字符串为例,则:

当您需要传递字符串时,请将其作为 const char * 传递。当你
需要 DLL 函数返回一个字符串,将 char * 传递给 DLL
指向预分配缓冲区的指针,DLL 将在其中写入
字符串。

最后,关于内存分配,那么:

切勿在 DLL 自身之外使用由 DLL 分配的内存
函数,并且永远不会传递有自己的值结构
构造函数/析构函数。

参考

从函数返回时堆损坏在 dll 内

我可以吗将 std::string 传递给 DLL?

You should distinguish between tightly coupled and loosely coupled DLLs.

Tightly coupled DLLs mean that

the DLL is built with the exact same compiler version, packing and
calling convention settings, library options as the application, and
both dynamically link to the runtime library (/MD compiler option).
This lets you pass objects back and forth including STL containers,
allocate DLL objects from inside the application, derive from base
classes in the other module, do just about everything you could
without using DLLs. The disadvantage is that you can no longer
deploy the DLL independently of the main application. Both must be
built together. The DLL is just to improve your process startup time
and working set, because the application can start running before
loading the DLL (using the /delayload linker option). Build times
are also faster than a single module, especially when whole program
optimization is used. But optimization doesn't take place across the
application-DLL boundary. And any non-trivial change will still
require rebuilding both.

In case of loosely coupled DLLs, then

When exporting DLL functions, it's best if they accept only integral
data types, i.e. int or pointers.

With reference, for example, to strings, then:

When you need to pass a string, pass it as a const char *. When you
need the DLL function to return a string, pass to the DLL a char *
pointer to a pre-allocated buffer, where the DLL would write the
string.

Finally, concerning memory allocation, then:

Never use memory allocated by the DLL outside of the DLL's own
functions, and never pass by value structures that have their own
constructor/destructor.

References

Heap corruption when returning from function inside a dll

Can I pass std::string to a DLL?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文