Question

我做了一个非常简单的程序，它为我自动化了一些东西。我用c ++编写它，它在Windows上运行。在Codeblocks IDE内部使用GDB进行调试时，我无处可获得许多断点。我不知道可能导致这个问题的原因。断点似乎与内存问题有关...因为当我修复了我检测到的内存泄漏时，断点数量明显减少了。

gdb告诉我的确切事实是：

 Program received signal SIGTRAP, Trace/breakpoint trap.
 In ntdll!TpWaitForAlpcCompletion () (C:\Windows\system32\ntdll.dll)

我在程序中多次得到这个。我认为我可能会做一些非常错误的事情，即使程序看起来运行得很好并且它完成了我想要它做的事情。任何人都可以告诉我这是什么问题，因为我不知道在哪里看？如果它不是问题，那么有没有人知道如何禁用它，因为这阻止我进入我自己设置的断点？

提前致谢！

编辑:(添加GDB的where命令的输出）：我在哪里可以查看每个功能的作用，这样我就可以看到我做错了什么？

#0  0x76fefadd in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll
#1  0x0028e894 in ?? ()
#2  0x76fb272c in ntdll!RtlCreateUserStack () from C:\Windows\system32\ntdll.dll
#3  0x00657fb8 in ?? ()
#4  0x00657fb8 in ?? ()
#5  0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#6  0x02070005 in ?? ()
#7  0x00000b10 in ?? ()
#8  0x0028e8dc in ?? ()
#9  0x76ff0b37 in ntdll!TpQueryPoolStackInformation () from C:\Windows\system32\ntdll.dll
#10 0x038b0000 in ?? ()
#11 0x00657fb8 in ?? ()
#12 0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#13 0x6e6e9a5e in ?? ()
#14 0x038b0000 in ?? ()
#15 0x038b0000 in ?? ()
#16 0x00000000 in ?? ()

Answer 1

虽然这个问题已经很老了，但是有些观点可能会帮助那些像我一样在搜索后来到这里的人：

我在Win7上测试我刚刚在WinXP上开发的应用程序时遇到了这个问题。就我而言，它与Windows 7内存管理监控和我的应用程序中的内存分配不良有关。

为了简化故事，在应用程序代码中，一个由错误（而不是使用GlobalAlloc()）进行了malloced的内存块并被GlobalFree()释放（这是错误的，因为系统使用来自C运行时内存池的指针访问堆）。虽然这会导致（在这种情况下非常小）内存泄漏，但在WinXP上测试时却完全没有注意到，并且整个程序显然运行正常。

现在在Win7上执行时，名为Fault Tolerant Heap（FTH）的内存监控功能会检测到应用程序的这个错误（导致异常）：

同时它通过OutputDebugString()（或者DbgPrint()）输出一些信息，可以使用简单的DebugView工具查看，也可以在跟踪时通过任何调试器查看应用程序。因此，在收到信号之前，您可以在消息中看到类似的内容：

警告：HEAP [name_of_your.exe]：

警告：为RtlFreeHeap指定的地址无效（006B0000,006A3698）
并且（在调试应用程序的情况下）它输出一个在调试器之外没有任何影响的断点，但是这应该有助于指出问题。 该断点显示为GDB的SIGTRAP信号。

此时您有两种选择：

尝试遍历调用堆栈以查找代码中的错误指令（遗憾的是，在这种情况下，bt或where gdb命令显示得不够远，无法查看代码中堆的位置错误释放 - 如果有人知道如何从启动模块而不是ntdll显示正确的调用堆栈，请告诉我）
尝试继续，因为FTH能够在内存中自动修补，以尝试解决您的错误（自动补丁也可以在下次运行应用程序时提前发生）。

如果没有在堆问题时停止，正如Moshe Levi所说，您可以在启动应用程序之前在GDB提示符处设置handle SIGTRAP nostop。

简而言之：是的，您的代码相对于内存管理确实存在问题，但在某些情况下，它可以在不崩溃的情况下运行。但是在调试模式下，内核会尝试将您置于问题的路径上。

Answer 2

哇，你把我送回了5年，当我在linux平台上使用gdb时：）

使用以下命令接收SIGTRAP时可以阻止gdb中断：

handle SIGTRAP nostop

但我在这里史蒂夫，请尝试使用WinDbg。它专为Windows而构建。

Answer 3

我建议使用本机Windows调试器WinDBG。这将为符号转换为内核模式时提供更好的堆栈跟踪。

Answer 4

我刚刚使用gt / mingw和Qt Creator一起经历了这次崩溃。

我也有其他问题，包括似乎错误的变量（偏移6个字节）。就我而言，它结果是一个破坏代码的pragma包。

我有这个：

#pragma pack(1)
typedef struct SomeStruct
{
... // structure
} SomeStruct;

...但是我没有使用pragma pack（）调用终止它，结束后返回1的包装并返回默认的字节对齐/打包。添加修复它：

#pragma pack(1)
typedef struct SomeStruct
{
... // structure
} SomeStruct;
#pragma pack() // <<-- with this line the heap corruption problem was stopped

在ntdll内部使用gdb进行调试时，断点无处不在

4 个答案: