Problem pausing debugger using TDM-GCC64, C::B v13.12

[oBFusCATed]

Can you post a log from a command ling gdb session?

[ollydbg]

I guess the GDB stack sniffer just failed to unwind a frame. This is because when you halt the debugee, it may paused in a system dll which does not have any debug information GDB knows. (Maybe, you can try a more recent GDB to see its sniffer get more robust

Do the below steps work after those situation happens? (either in the command line or under C::B)

Code

1, set a bp in the line such as "++x;", 
2, you run the continue command
3, the debugee will hit this breakpoint.

I used glindsey's code from this topic. After pausing the debugger, this is all I get from the debugger log:
....
At this moment, I can resume the program and it runs. I can set a breakpoint in the code and it stops there. But I can't get to the program code in which the program is at the moment of pausing (the loop in this example). As you see, the program is not even in the stack trace.
...

Oh, it looks like you can hit the BP, which verify my guess.

I can't get to the program code

This means GDB can't map the instruction address to source code location. 

[Vuki]

Can you post a log from a command ling gdb session?

I've compiled the latest gdb 7.7.1 but it didn't help. Seems it's a limitation of gdb on 64-bit windows.
gdb log below.

Code

Reading symbols from ttt.exe...done.
(gdb) r
Starting program: c:\C\MinGW\MSYS\home\Greg\gdb-7.7.1\_build\bin\ttt.exe
[New Thread 10800.0x1a38]
Hello world!
0... Pausing for a second...
1... Pausing for a second...
2... Pausing for a second...
3... Pausing for a second...
[New Thread 10800.0x1588]

Program received signal SIGINT, Interrupt.
[Switching to Thread 10800.0x1588]
0x0000000077a449f2 in KERNEL32!CtrlRoutine ()
   from C:\Windows\system32\kernel32.dll
(gdb) bt
#0  0x0000000077a449f2 in KERNEL32!CtrlRoutine ()
   from C:\Windows\system32\kernel32.dll
#1  0x0000000077a059ed in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#2  0x0000000077c3c541 in ntdll!RtlUserThreadStart ()
   from C:\Windows\system32\ntdll.dll
#3  0x0000000000000000 in ?? ()
(gdb) c
Continuing.
[Thread 10800.0x1588 exited with code 0]
4... Pausing for a second...
5... Pausing for a second...
6... Pausing for a second...
[New Thread 10800.0x1c60]

Program received signal SIGINT, Interrupt.
[Switching to Thread 10800.0x1c60]
0x0000000077a449f2 in KERNEL32!CtrlRoutine ()
   from C:\Windows\system32\kernel32.dll
(gdb) bt
#0  0x0000000077a449f2 in KERNEL32!CtrlRoutine ()
   from C:\Windows\system32\kernel32.dll
#1  0x0000000077a059ed in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#2  0x0000000077c3c541 in ntdll!RtlUserThreadStart ()
   from C:\Windows\system32\ntdll.dll
#3  0x0000000000000000 in ?? ()
(gdb) b 13
Breakpoint 1 at 0x401571: file ttt.cpp, line 13.
(gdb) c
Continuing.
[Switching to Thread 10800.0x1a38]

Breakpoint 1, main () at ttt.cpp:13
13          ++x;
(gdb)

[ollydbg]

Hi, Vuki, in the previous post, do you press the CTRL+C to stop the debugee? I mean can we send a CTRL+C signal to debugee or GDB to halt the debugee.

Something like: http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-objects-on-windows

[Vuki]

I do press CTL+C, because it's the only way I know to stop GDB in command line. But since it does not return to the program, I doubt that it would be better solution than the current one. From the discussion so far, it seems that the problem is on the gdb side.

[ollydbg]

I see some source code in GDB: windows-nat.c

Code

/* Wait for interesting events to occur in the target process.  */
static ptid_t
windows_wait (struct target_ops *ops,
	      ptid_t ptid, struct target_waitstatus *ourstatus, int options)
{
  int pid = -1;

  target_terminal_ours ();

  /* We loop when we get a non-standard exception rather than return
     with a SPURIOUS because resume can try and step or modify things,
     which needs a current_thread->h.  But some of these exceptions mark
     the birth or death of threads, which mean that the current thread
     isn't necessarily what you think it is.  */

  while (1)
    {
      int retval;

      /* If the user presses Ctrl-c while the debugger is waiting
	 for an event, he expects the debugger to interrupt his program
	 and to get the prompt back.  There are two possible situations:

	   - The debugger and the program do not share the console, in
	     which case the Ctrl-c event only reached the debugger.
	     In that case, the ctrl_c handler will take care of interrupting
	     the inferior.  Note that this case is working starting with
	     Windows XP.  For Windows 2000, Ctrl-C should be pressed in the
	     inferior console.

	   - The debugger and the program share the same console, in which
	     case both debugger and inferior will receive the Ctrl-c event.
	     In that case the ctrl_c handler will ignore the event, as the
	     Ctrl-c event generated inside the inferior will trigger the
	     expected debug event.

	     FIXME: brobecker/2008-05-20: If the inferior receives the
	     signal first and the delay until GDB receives that signal
	     is sufficiently long, GDB can sometimes receive the SIGINT
	     after we have unblocked the CTRL+C handler.  This would
	     lead to the debugger stopping prematurely while handling
	     the new-thread event that comes with the handling of the SIGINT
	     inside the inferior, and then stop again immediately when
	     the user tries to resume the execution in the inferior.
	     This is a classic race that we should try to fix one day.  */
      SetConsoleCtrlHandler (&ctrl_c_handler, TRUE);
      retval = get_windows_debug_event (ops, pid, ourstatus);
      SetConsoleCtrlHandler (&ctrl_c_handler, FALSE);

So, it looks like CTRL+C should work. But I don't know how to send a CTRL+C from Codeblocks(32bit) to GDB(64bit).

[oBFusCATed]

See the logic for interrupting the debugger for remote debugging on windows.

It opens a console and sends the SIGINT equivalent. On Linux I couldn't make sending SIGINT directly to gdb to work as far as I remember.