Author Topic: Problem pausing debugger using TDM-GCC64, C::B v13.12  (Read 21156 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #15 on: May 13, 2014, 09:12:59 am »
Can you post a log from a command ling gdb session?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #16 on: May 13, 2014, 09:13:22 am »
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.
Quote
I can't get to the program code
This means GDB can't map the instruction address to source code location.  :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Vuki

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #17 on: May 13, 2014, 02:51:13 pm »
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)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #18 on: May 13, 2014, 03:08:32 pm »
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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Vuki

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #19 on: May 14, 2014, 09:13:39 am »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #20 on: May 24, 2014, 05:38:35 am »
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).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem pausing debugger using TDM-GCC64, C::B v13.12
« Reply #21 on: May 24, 2014, 09:44:40 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]