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

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

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

我刚刚在WinX上测试我在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或者wheregdb命令显示得不够远,无法看到我的代码中错误释放堆的位置 - 如果有人知道如何显示正确的调用堆栈从起始模块而不是ntdll,让我知道)
• 尝试继续,因为FTH能够在内存中自动修补,以尝试解决您的错误(自动补丁也可以在应用程序的下一次运行时提前发生)

为了在堆问题时不停止,正如Moshe Levi所说,您可以handle SIGTRAP nostop在启动应用程序之前在GDB提示符处设置.

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

Answer 2

哇,你把我送回了5年,当时我在linux平台上使用了gdb :)

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

handle SIGTRAP nostop

但是我在这里史蒂夫,请尝试使用WinDbg.它专为Windows而建.