Breakpoints out of nowhere when debugging with gdb, inside ntdll

Question

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

Answer 1

Wow, you sent me back 5 years to when I used gdb on the linux platform :)

you can prevent gdb to break when receiving SIGTRAP with the following command:

handle SIGTRAP nostop

But I'm with steve here, Try WinDbg instead. It was built especially for windows.

Answer 2

I just experienced this crash using gcc/mingw with Qt Creator.

I had other problems, too, including variables that seemed to be wrong (offset by 6 bytes). In my case, it turned out to be a pragma pack that wreaked havoc on the code.

I had this:

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

... but I didn't terminate it with a pragma pack() call to end packing of 1 after the structure and return to the default byte alignment/packing. Adding that fixed it:

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

Answer 3

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.

Answer 4

I'd recommend to use WinDBG, the native windows debugger. This will give better stack traces especially for the symbols when it transitions to kernel mode.