From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9551 invoked by alias); 10 May 2008 17:22:45 -0000 Received: (qmail 9542 invoked by uid 22791); 10 May 2008 17:22:44 -0000 X-Spam-Check-By: sourceware.org Received: from pool-72-74-94-32.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (72.74.94.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 May 2008 17:22:27 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id CDCC66BD001; Sat, 10 May 2008 13:22:24 -0400 (EDT) Date: Sun, 11 May 2008 05:30:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [RFC] control-c handling on Windows... Message-ID: <20080510172224.GA24393@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <20080507205611.GB7421@adacore.com> <20080509202942.GA4386@ednor.casa.cgf.cx> <20080510013336.GC28890@adacore.com> <20080510043413.GA5429@ednor.casa.cgf.cx> <20080510153102.GE28890@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080510153102.GE28890@adacore.com> User-Agent: Mutt/1.5.16 (2007-06-09) 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/msg00342.txt.bz2 On Sat, May 10, 2008 at 08:31:02AM -0700, Joel Brobecker wrote: >Hi Chris, > >> I think the way this is handled in linux is by resetting the controlling >> process group of the terminal to the pid of the inferior. On thinking >> about this more, I think it probably makes more sense to bracket the >> call with: >> >> SetConsoleCtrlHandler (NULL, TRUE); >> retval = get_win32_debug_event (pid, ourstatus); >> SetConsoleCtrlHandler (NULL, FALSE); >> >> That's almost equivalent to what linux does with process groups I think. >> >> Does the above work in your scenario, Joel? If so, I think this is >> safe to check in. > >I think it does work. All my experiments at resuming the inferior after >having interrupted it with C-c have been succesful. > >The only problem is that once in a while GDB still receives the SIGINT. >This time, it doesn't cause the debugger to QUIT during the resume after >handling the new-thread event like it used to, so we properly report the >SIGINT event to the user: > > (gdb) cont > Continuing. > I = 10 > I = 11 > I = 12 > [New thread 2348.0x1550] <<<--- pressed C-c > > Program received signal SIGINT, Interrupt. > [Switching to thread 2348.0x1550] > 0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT when the program is resumed) > >However, because the SIGINT handler was called, we still get the unexpected >"Quit (expect signal SIGINT when the program is resumed" message in >the middle of printing the current frame. As I said earlier, it doesn't >prevent the next resume to work properly. It's a little misleading but >I think this is already a good improvement, so I suggest we go with your >suggestion. I think there is obviously a race here. Possibly just calling SetConsoleCtrlHandler (NULL, TRUE) before calling CreateProcess is all that's required to handle it but looking at inflow.c it seems like the process group handling that gdb is expecting is more complicated than a turn-it-all-off or turn-it-all-on. I assume that you're using a mingw version of cygwin so I don't know the setting for the job_control variable. If it is off, it seems like it should be doing the right thing already. If it's on then I could see that as being a problem. Or, maybe it would make sense to use job_control as it was intended. We could kludge up a tcsetpgrp for windows which messed with CTRL-C handling for gdb based on whether it was being called with the gdb process group or the inferior process group. This is under the assumption that the race you're seeing is already being handled by gdb but is being bypassed because the windows platform doesn't have enough capabilities to do the right thing. cgf