获取随机SIGTRAP信号（在MinGW-gdb）是内存损坏的迹象吗？ [英] Does getting random SIGTRAP signals (in MinGW-gdb) is a sign of memory corruption?

问题描述

我写了我自己的引用计数内存管理器c ++（为了乐趣），我相信它不完美）。现在当我试图使用它我有随机SIGTRAP信号。如果我注释掉与该内存管理器连接的每一行，一切运行正常。获取SIGTRAP-s而不是SIGSEGV是相当奇怪。
我知道当程序命中一个断点，但没有设置断点时，SIGTRAP被抛出。我在另一个线程中读取的exe和dll的调试版本必须是最新的。

I wrote my own reference counted memory manager c++ (for fun) and I'm sure it isn't perfect ;) . And now when I'm trying to use it I got random SIGTRAP signals. If I comment out every line which are in connection with that memory manager everything runs fine. Getting SIGTRAP-s instead of SIGSEGV is quite strange. I know that SIGTRAP-s are thrown when the program hits a breakpoint, but no breakpoint is set. I read in an other thread that debug builds of the exe's and dll's must be up to date. They are up to date and so it is not the reason.

有人知道为什么会发生这种情况吗？

Does anyone know why is this happening?

推荐答案

在Google上搜索后，我意识到那些sigtraps是相同的，你在MSVC ++中得到的警告说Windows已经触发了xxxx.exe中的断点，这可能是由于堆，并指示错误blahblahblah...

After searching on Google I realized that those sigtraps are same as those warnings you get in MSVC++ saying "Windows has triggered a breakpoint in xxxx.exe. This may be due to a corruption of the heap, and indicates a bug blahblahblah"...

所以似乎是，意想不到的sigtraps可以指示内存损坏（很奇怪...）

So it seems yes, unexpected sigtraps can indicate memory corrupction (quite strange...)

我也发现了我的错误。 MM在一个静态库中，它链接到一个dll。和静态lib和DLL链接到我的exe。所以有两个内存管理器，一个在我的exe和一个在我的dll。如果调用MM的initaialization方法。它初始化MM在我的exe，但不是在dll所以dll没有init。我通过不将我的exe链接到静态库来解决这个问题。

And I found my bug too. The MM is in a static library which is linked to a dll. And that static lib and the dll is linked to my exe. So there were two memory managers, one in my exe and one in my dll. If call the initaialization method of the MM. It initialized the MM in my exe but not in the dll so the dll went without init. I solved this by not linking my exe against that static library.

这篇关于获取随机SIGTRAP信号（在MinGW-gdb）是内存损坏的迹象吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！