From: Joel Brobecker <brobecker@gnat.com>
Date: Tue, 20 May 2008 18:36:36 +0000 (+0000)
Subject:         * win32-nat.c (win32_wait): Block the control-c event while
X-Git-Tag: msnyder-reverse-20080609-branchpoint~180
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c57918b25bb19d8ecaaad7eee1d372ffaf44d857;p=thirdparty%2Fbinutils-gdb.git

    * win32-nat.c (win32_wait): Block the control-c event while
        waiting for a debug event.
---

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 186ee9e8a00..7a9b52944e0 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2008-05-20  Joel Brobecker  <brobecker@adacore.com>
+
+	* win32-nat.c (win32_wait): Block the control-c event while
+	waiting for a debug event.
+
 2008-05-19  Pedro Alves  <pedro@codesourcery.com>
 
 	* symtab.h (lookup_symbol_in_language): Update comment.
diff --git a/gdb/win32-nat.c b/gdb/win32-nat.c
index d597b69c8ca..52ff20a20ae 100644
--- a/gdb/win32-nat.c
+++ b/gdb/win32-nat.c
@@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus)
 
   while (1)
     {
-      int retval = get_win32_debug_event (pid, ourstatus);
+      int retval;
+      
+      /* Ignore CTRL+C signals while waiting for a debug event.
+         FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
+         the inferior is running, both the inferior and GDB receive the
+         associated signal.  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 to stop
+         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, and it would be nice
+         to find a better solution to that problem.  But in the meantime,
+         the current approach already greatly mitigate this issue.  */
+      SetConsoleCtrlHandler (NULL, TRUE);
+      retval = get_win32_debug_event (pid, ourstatus);
+      SetConsoleCtrlHandler (NULL, FALSE);
+
       if (retval)
 	return pid_to_ptid (retval);
       else
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index d597b69c8ca..52ff20a20ae 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus)
 
   while (1)
     {
-      int retval = get_win32_debug_event (pid, ourstatus);
+      int retval;
+      
+      /* Ignore CTRL+C signals while waiting for a debug event.
+         FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
+         the inferior is running, both the inferior and GDB receive the
+         associated signal.  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 to stop
+         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, and it would be nice
+         to find a better solution to that problem.  But in the meantime,
+         the current approach already greatly mitigate this issue.  */
+      SetConsoleCtrlHandler (NULL, TRUE);
+      retval = get_win32_debug_event (pid, ourstatus);
+      SetConsoleCtrlHandler (NULL, FALSE);
+
       if (retval)
 	return pid_to_ptid (retval);
       else