From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19165 invoked by alias); 7 Feb 2009 10:08:24 -0000 Received: (qmail 19156 invoked by uid 22791); 7 Feb 2009 10:08:23 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rv-out-0708.google.com (HELO rv-out-0708.google.com) (209.85.198.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 07 Feb 2009 10:08:17 +0000 Received: by rv-out-0708.google.com with SMTP id b17so1099280rvf.48 for ; Sat, 07 Feb 2009 02:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.137.6 with SMTP id p6mr2088896rvn.133.1234001295840; Sat, 07 Feb 2009 02:08:15 -0800 (PST) In-Reply-To: <20090206164254.GZ3683@adacore.com> References: <308806.32791.qm@web36206.mail.mud.yahoo.com> <20090206164254.GZ3683@adacore.com> Date: Sat, 07 Feb 2009 10:08:00 -0000 Message-ID: Subject: Re: What happened in gdb between handle_sigint and async_request_quit? From: "Amker.Cheng" To: gdb@sourceware.org Cc: Joel Brobecker , paawan1982@yahoo.com, teawater Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00068.txt.bz2 Hi Joel: Thanks for the detailed explanation, It's very helpful. The patch you mentioned was applied after the release of version 6.8, I was wondering then why GDB stops twice at a great probability when one CTRL+C being hit. But one more question, where GDB blocks CTRL+C handler? I was thinking that the handler "handle_sigint" is always registered during waiting for inferior's event. Thanks a lot. Regards. On Sat, Feb 7, 2009 at 12:42 AM, Joel Brobecker wrote: >> both of GDB and Debuggee will get the event. Windows will report DBG_CONTROL_C >> exception to GDB, which was turned into TARGET_SIGNAL_INT in GDB. >> According to MSDN, this is the First Chance Exception! > > The situation on Windows is different from the situation on Unix. > On Unix, we give the terminal back to the inferior while the inferior > is running. So, when a user presses Ctrl-c, only the inferior gets > the signal. This signal triggers a debug event to GDB and suspends > the inferior, and GDB treats this signal as it would treat any other > signal. On Windows, things are a little trickier, because the inferior > and GDB might be running in the same console. This means that, when > the user presses Ctrl-c, then *both* GDB and the inferior get the > associated signal. But we don't actually want GDB to receive the signal, > so we simply temporarily ignore all Ctrl-C signals in GDB while the > inferior is waiting: > > /* 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_windows_debug_event (pid, ourstatus); > SetConsoleCtrlHandler (NULL, FALSE); > > The code above assumes that the inferior and GDB are running in > the same console, which is not always the case. Currently, when > this is the case, the only way to interrupt your program is by > pressing Ctrl-c in the console where your program is running. > There is patch pending that enhances GDB to handle the case when > the inferior is running in a separate console. > > -- > Joel >