Re: [RFC] control-c handling on Windows...

Joel Brobecker
2008-05-10T01:33:59Z

[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

Hi Chris,

> Thanks for the analysis. I've talked to Corinna about this since she
> was responsible for the original patch in question. I think her patch
> still makes sense so I guess your change is required although I can't
> shake the feeling that there is some CreateProcess setting that we're
> missing to deal with this behavior.

I had a second look at the issue that Corinna was facing. I am not
entirely sure that I'm seeing the exact same problem, but the symptoms
are the same (gdbtui's process goes into background).

As far as I can tell, here is the sequence of events that lead to
the problem:

1. win32_create_inferior creates the process, and then calls
do_initial_win32_stuff.
2. do_initial_win32_stuff then gives the terminal to the inferior,
and then does a wait_for_inferior () until we get the expected
SIGTRAP.
3. wait_for_inferior leads us to calling win32_wait which calls
which in turn calls get_win32_debug_event.
4. As expected, we get our CREATE_PROCESS_DEBUG_EVENT. As a result,
we add this new pid to the list of threads calling
win32_add_thread.
5. win32_add_thread calls add_thread as well, which calls
add_thread_with_info. This is where things get interesting:

if (print_thread_events)
printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));

When I remove this printf_unfiltered, the startup phase completes fine.
I was going to propose that we therefore remove the target_terminal_ours
out of win32_wait and bracket the call to add_thread with
target_terminal_ours/target_terminal_inferior. Things seemed to work
relatively fine, except that I occasionally got the wrong behavior
when pressing C-c. Also, the new suggestion would not take care of
the multiple DEBUG traces that we can get GDB to print.

As far as I can tell, it almost looks like the SIGINT is buffered
until we switch the terminal to the debugger. Using printfs,
the sequence I see is: we see the new thread, we switch the terminal
to ours to print the new thread event, we receive the SIGINT...
I just don't understand.

> But, if your patch fixes the problem I'm ok with checking it in.

I think that this is probably the easiest to solve all problems.
Here is the same patch, but with a comment explaining why we temporarily
ignore SIGINT...

2008-05-10 Joel Brobecker <brobecker@adacore.com>

* win32-nat.c (win32_wait): Ignore SIGINT while waiting for
a debug event.

I thought you might have some comments/suggestions on the comment,
so I'll wait for your OK before checking it in.

Thanks,
--
Joel

[-- Attachment #2: win32-nat.c.diff --]
[-- Type: text/plain, Size: 1046 bytes --]

Index: win32-nat.c
===================================================================
--- win32-nat.c (revision 130731)
+++ win32-nat.c (working copy)
@@ -1467,7 +1467,20 @@ win32_wait (ptid_t ptid, struct target_w

while (1)
{
- int retval = get_win32_debug_event (pid, ourstatus);
+ int retval;
+ void (*ofunc) (int);
+
+ /* For some reason, even when the terminal is owned by the inferior,
+ pressing control-c in the debugger window sometimes leads to
+ the debugger getting the associated SIGINT, which is unexpected.
+ In fact, both the inferior and the debugger get this signal.
+ To avoid getting this signal in the debugger, we temporarily
+ ignore SIGINT while waiting for debug events. However, this
+ might be a symptom of a problem in our terminal settings. */
+ ofunc = signal (SIGINT, SIG_IGN);
+ retval = get_win32_debug_event (pid, ourstatus);
+ signal (SIGINT, ofunc);
+
if (retval)
return pid_to_ptid (retval);
else