From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFC] control-c handling on Windows...
Date: Wed, 21 May 2008 00:34:00 -0000 [thread overview]
Message-ID: <20080520183820.GB3895@adacore.com> (raw)
In-Reply-To: <20080516193438.GA4413@ednor.casa.cgf.cx>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
Hi Chris,
> Checking this in is ok with me but it would be nice to consider a better
> solution eventually. Could you put a note to that effect in the patch
Attached is the patch that I ended up checking in. Let me know if you'd
like me to make some adjustments to the comment...
2008-05-20 Joel Brobecker <brobecker@adacore.com>
* win32-nat.c (win32_wait): Block the control-c event while
waiting for a debug event.
--
Joel
[-- Attachment #2: win32-nat.c.diff --]
[-- Type: text/plain, Size: 1598 bytes --]
Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.151
diff -u -p -r1.151 win32-nat.c
--- win32-nat.c 11 Mar 2008 05:21:38 -0000 1.151
+++ win32-nat.c 20 May 2008 18:33:29 -0000
@@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_w
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
next prev parent reply other threads:[~2008-05-20 18:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 9:46 Joel Brobecker
2008-05-10 4:34 ` Christopher Faylor
2008-05-10 13:10 ` Joel Brobecker
2008-05-10 15:31 ` Christopher Faylor
2008-05-10 22:28 ` Joel Brobecker
2008-05-11 5:30 ` Christopher Faylor
2008-05-11 13:31 ` Joel Brobecker
2008-05-11 13:46 ` Eli Zaretskii
2008-05-11 13:58 ` Christopher Faylor
2008-05-11 21:26 ` Joel Brobecker
2008-05-17 11:38 ` Christopher Faylor
2008-05-21 0:34 ` Joel Brobecker [this message]
2008-05-21 3:19 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080520183820.GB3895@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox