From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12517 invoked by alias); 10 May 2008 19:42:53 -0000 Received: (qmail 12420 invoked by uid 22791); 10 May 2008 19:42:52 -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 19:42:34 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id EA4326BD001; Sat, 10 May 2008 15:42:32 -0400 (EDT) Date: Sun, 11 May 2008 13:58:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [RFC] control-c handling on Windows... Message-ID: <20080510194232.GC17229@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, Joel Brobecker 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> <20080510180010.GF28890@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080510180010.GF28890@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/msg00345.txt.bz2 On Sat, May 10, 2008 at 11:00:10AM -0700, Joel Brobecker wrote: >> If only I understood signals and terminals better, I would try to >> understand the reason why GDB still gets the SIGINT despite all our >> efforts. But, right now, I'm a little in the dark :(. I know that >> Nicolas Roche, one of the engineers at AdaCore, has spent quite >> a bit of time studying this sort of issues, so I'll see if I can >> nudge him a little out of his busy schedule to share some of the ideas >> he had. > >I spoke with Nico a little. He is pretty certain, based on what he read >of the Windows documentation, that we cannot avoid having GDB receive >the SIGINT. Apparently, the console is responsible for sending those >signals, and its behavior cannot be changed. > >I wonder if there might be some sort of timing issue that causes >the signal to sometimes be delivered after we stopped ignoring control >events. In other words, some of the time, we receive the signal >reasonably close to when we receive the debug event for the new thread, >and so it gets ignored. But some other time, we receive the signal >sufficiently after we got the debug event that we already got out of >get_win32_debug_event and restored the regular SIGINT handler... >That would explain why we're seeing the QUIT message. i.e., it's a classic race. >So the problem becomes when to handle the signal and when to ignore it. >I'll keep thinking about it for a while, but I haven't found a solution >yet. > >On a side note, utils.c:quit is: > > void > quit (void) > { > #ifdef __MSDOS__ > /* No steenking SIGINT will ever be coming our way when the > program is resumed. Don't lie. */ > fatal ("Quit"); > #else > if (job_control > /* If there is no terminal switching for this target, then we can't > possibly get screwed by the lack of job control. */ > || current_target.to_terminal_ours == NULL) > fatal ("Quit"); > else > fatal ("Quit (expect signal SIGINT when the program is resumed)"); > #endif > } > >Not sure when __MSDOS__ is defined, but perhaps we should extend >that case to mingw & cygwin as well? At least we wouldn't get the >"expect signal SIGINT when the program is resumed" part which >I don't think can happen on Windows anymore. I'm still assuming that you're talking about mingw here since Cygwin should have different behavior. For instance, it implements tcsetpgrp. cgf