Unable to step through program in gdb after SIGTRAP

Question

Using mingw gdb, when I to break the program as it's running (using the method from In GDB on MinGW, how do I make Ctrl-C stop the program?), gdb fails to pick up from there.

The only backtrace information I can get is

#0  0x00007fffbfccd881 in ntdll!DbgBreakPoint () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffbfcf99fb in ntdll!DbgUiRemoteBreakin () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffbd473034 in KERNEL32!BaseThreadInitThunk ()
   from /c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffbfca1431 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

and if I try to step through the program I get

Single stepping until exit from function ntdll!DbgUiRemoteBreakin,
which has no line number information.

and the program runs to completion. I am able to step through normally (after a breakpoint) but I can't seem to get the debugger to recover from a SIGTRAP

You are now in a new thread created only for the DebugBreak(), so you have to switch back to one of your threads. Use info threads for list, and switch with thread YOUR_THREAD_NUMBER. — ssbssa
@ssbssa You are correct, I just tested an it worked like a charm. Would you make it into a proper answer that I can accept? — rtpax

ssbssa ssbssa · Accepted Answer · 2018-09-05T20:34:42

DebugBreakProcess creates a new thread in the target process, which is then signalling the debugger via a breakpoint exception to pause the execution.

You can list all available threads with info threads, and then switch to another thread via thread YOUR_THREAD_NUMBER.

Unable to step through program in gdb after SIGTRAP

1 Answers