From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2455 invoked by alias); 10 May 2008 01:33:59 -0000 Received: (qmail 2441 invoked by uid 22791); 10 May 2008 01:33:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 May 2008 01:33:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 98DE82A9982 for ; Fri, 9 May 2008 21:33:39 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kbQ8UD5vzD3q for ; Fri, 9 May 2008 21:33:39 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2C7812A9929 for ; Fri, 9 May 2008 21:33:39 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 120B0E7ACD; Fri, 9 May 2008 18:33:37 -0700 (PDT) Date: Sat, 10 May 2008 13:10:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC] control-c handling on Windows... Message-ID: <20080510013336.GC28890@adacore.com> References: <20080507205611.GB7421@adacore.com> <20080509202942.GA4386@ednor.casa.cgf.cx> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20080509202942.GA4386@ednor.casa.cgf.cx> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00333.txt.bz2 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2607 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 * 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 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="win32-nat.c.diff" Content-length: 1046 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 --gKMricLos+KVdGMg--