在ntdll内部使用gdb进行调试时，断点无处不在 [英] Breakpoints out of nowhere when debugging with gdb, inside ntdll

问题描述

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

gdb的确切事情告诉我是：

 程序接收信号SIGTRAP，跟踪/断点陷阱。 
在ntdll！TpWaitForAlpcCompletion（）（C：\Windows\system32\\\
tdll.dll）
  

$ b $我在我的程序中很多次了。我认为我可能正在做一些非常错误的事情，即使这个程序似乎运行得很好，它完成了我想做的事情。有谁能告诉我什么问题，因为我不知道在哪里看？另外如果这不是问题，那么有没有人知道如何禁用它，因为这阻止我进入我设置的断点？

提前感谢！编辑：（添加GDB的命令在哪里命令）：
哪里可以查看这些功能，所以我可以看到我做错了什么？

 ＃0 0x76fefadd in ntdll！TpWaitForAlpcCompletion（）from C：\Windows\system32\\\
tdll.dll 
＃1 0x0028e894在?? （）
＃2 0x76fb272c in ntdll！RtlCreateUserStack（）from C：\Windows\system32\\\
tdll.dll 
＃3 0x00657fb8 in ?? （）
＃4 0x00657fb8 in ?? （）
＃5 0x76f4b76a在ntdll！RtlDowncaseUnicodeChar（）从C：\Windows\system32\\\
tdll.dll 
＃6 0x02070005在?? （）
＃7 0x00000b10 in ?? （）
＃8 0x0028e8dc in ?? （）
＃9 0x76ff0b37 in ntdll！TpQueryPoolStackInformation（）from C：\Windows\system32\\\
tdll.dll 
＃10 0x038b0000 in ?? （）
＃11 0x00657fb8 in ?? （）
＃12 0x76f4b76a在ntdll！RtlDowncaseUnicodeChar（）从C：\Windows\system32\\\
tdll.dll 
＃13 0x6e6e9a5e在?? （）
＃14 0x038b0000 in ?? （）
＃15 0x038b0000 in ?? （）
＃16 0x00000000 in ?? （）
  

解决方案

虽然这个问题现在很老了，有一些点可能会帮助有人像我这样的搜索来到这里：

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

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

现在执行时在Win7上，内存监控功能称为容错堆（FTH）检测到该应用程序的错误（导致例外）：

• 同时它通过 OutputDebugString（）（或可能 DbgPrint（））输出一些信息，可以使用简单的<一个href =http://technet.microsoft.com/en-us/sysinternals/bb896647 =noreferrer> DebugView 工具，或任何调试器跟踪应用程序时。因此，在接收到的信号之前，您可以在消息中看到类似信息：

  
  

  警告：HEAP [name_of_your.exe]：

  
  
  

  警告：指定给RtlFreeHeap（006B0000，006A3698）的地址无效

  
  




• 并且（在应用程序被调试的情况下），它输出一个在调试器外没有效果的断点，但是这应该有助于指出问题。 该断点由GDB显示为SIGTRAP信号。

此时您有2个选项：

• 尝试走走调用堆栈，在代码中找到错误的指令（不幸的是，在这种情况下， bt 或其中 gdb命令无法显示足够多的位置，以便看到我的代码中的堆被错误地释放了 - 如果有人知道如何从开始模块而不是ntdll显示正确的调用堆栈，让我知道）


• 尝试继续，因为FTH能够自动修补内存，以尝试解决你的错误（这个自动补丁也可以在下一次运行的应用程序中提前发生）

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

$ b $所以简而言之：是的，你在你的c中确实有错误ode相对于内存管理，但在某些情况下它可以运行而不会崩溃。但是在调试模式下，内核尝试让您走上问题的路径。

I made a very simple program which automates some things for me.I wrote it in c++ and it runs on Windows. While debugging it with GDB from inside the Codeblocks IDE , I get many breakpoints out of nowhere. I have no idea what might be causing this problem. The breakpoints seem to be related with memory issues ... since when I fixed a memory leak I had detected, the breakpoints number got significantly less.

The exact thing that gdb tells me is:

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

I get this many many times inside my program. I think that I might be doing something very wrong, even though the program seems to run just fine and it accomplishes what I want it to do. Can anyone tell me what is the problem since I don't know where to look? Also if it is not a problem, then does anyone know how to disable it since this prevents me from getting to the breakpoints I set myself?

Thanks in advance!

EDIT: (Adding the output of GDB's where command): Where can I check what each of these functions do, so I can see what I am doing wrong?

#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 ?? ()

解决方案

While the question is quite old now, here are some points that might help someone that would come here after a search like I did:

I just encountered that problem while testing on Win7 an app developed by me on WinXP. In my case it is related both to Windows 7 memory management monitoring and a bad memory allocation in my app.

To make the story short, in the app code, a memory block that was malloced by error (instead of using GlobalAlloc()) and was freed with a GlobalFree() (which is wrong, as the system heap was accessed with a pointer from the C runtime memory pool). While this is causing a (very small in that case) memory leak, it was completely unnoticed while testing on WinXP and the whole program was running apparently correctly.

Now when executed on Win7, a memory monitoring feature called Fault Tolerant Heap (FTH) detects this bug of the app (that is causing an exception) :

• At the same time it is outputting some info via OutputDebugString() (or maybe DbgPrint()) that can be viewed using the simple DebugView tool, or by any debugger when tracing the application. Thus just before the received signal you can see something like that in the messages :

  warning: HEAP[name_of_your.exe]:

  warning: Invalid address specified to RtlFreeHeap( 006B0000, 006A3698 )

• And (in the case the app is being debugged) it outputs a breakpoint that has no effect outside of a debugger, but else that should help to point the problem. That breakpoint is shown as the SIGTRAP signal by GDB.

At this point you have 2 alternatives :

• try to walk the call stack to find the faulty instruction in your code (unfortunately in that case, the bt or where gdb commands cannot show far enough to see where in my code the heap was wrongly freed - if someone knows how to display the correct call stack from the starting module instead of ntdll, let me know)
• try to continue as FTH has the ability to automagically patch in memory as an attempt to work around your bug (that automagic patch can also occur in advance on the next run of the app)

For not stopping at the time of the heap problem, as Moshe Levi said, you can set a handle SIGTRAP nostop at the GDB prompt before starting the app.

So in short : yes you did have something wrong in your code relative to memory management but in some cases it can run without crashing. But in debug mode the kernel tries to put you on the path of the problem.

这篇关于在ntdll内部使用gdb进行调试时，断点无处不在的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！