From patchwork Wed Nov 25 16:07:48 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 9821 Received: (qmail 109555 invoked by alias); 25 Nov 2015 16:07:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 109545 invoked by uid 89); 25 Nov 2015 16:07:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f48.google.com Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Nov 2015 16:07:55 +0000 Received: by pacej9 with SMTP id ej9so61371698pac.2 for ; Wed, 25 Nov 2015 08:07:53 -0800 (PST) X-Received: by 10.98.2.70 with SMTP id 67mr32489016pfc.133.1448467673216; Wed, 25 Nov 2015 08:07:53 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id r79sm21758135pfa.61.2015.11.25.08.07.50 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 25 Nov 2015 08:07:52 -0800 (PST) From: Yao Qi To: gdb-patches@sourceware.org Subject: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp Date: Wed, 25 Nov 2015 16:07:48 +0000 Message-ID: <86ziy2xdt7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Hi, I am fixing a fail in gdb.base/random-signal.exp like this, Continuing.^M PASS: gdb.base/random-signal.exp: continue ^CPython Exception : ^M FAIL: gdb.base/random-signal.exp: stop with control-c (timeout) I only see this fail out of 15~20 runs each time. Is it because GDB received SIGINT before async_handle_remote_sigint is installed? so handle_sigint is still the SIGINT handler, set_quit_flag will call python stuff, and KeyboardInterrupt is raised as a result. In the test, we've already been aware of that the signal handler isn't ready, so "Continuing" is consumed and ctrl-c is delayed in 500ms. # For this to work we must be sure to consume the "Continuing." # message first, or GDB's signal handler may not be in place. after 500 {send_gdb "\003"} After I read the tcl manul about "after", I feel the usage of "after" above isn't 100% correct. As the manual says, the "after" command returns immediately, and the tcl command {send_gdb "\003"} will be executed 500 ms later. It is an asynchronous flavour, but what we want is a synchronous operation, like this, after 500 send_gdb "\003" with this change, I don't see the timeout fail again. Is it a fix or a hack? diff --git a/gdb/testsuite/gdb.base/random-signal.exp b/gdb/testsuite/gdb.base/random-signal.exp index 566668a..59c8f5b 100644 --- a/gdb/testsuite/gdb.base/random-signal.exp +++ b/gdb/testsuite/gdb.base/random-signal.exp @@ -38,5 +38,6 @@ gdb_test_multiple "continue" "continue" { # For this to work we must be sure to consume the "Continuing." # message first, or GDB's signal handler may not be in place. -after 500 {send_gdb "\003"} +after 500 +send_gdb "\003"