From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40157 invoked by alias); 25 Nov 2015 16:26:45 -0000 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 Received: (qmail 40145 invoked by uid 89); 25 Nov 2015 16:26:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Nov 2015 16:26:44 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 322D1C0B7AA4; Wed, 25 Nov 2015 16:26:43 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAPGQfUU006917; Wed, 25 Nov 2015 11:26:42 -0500 Message-ID: <5655E141.7030503@redhat.com> Date: Wed, 25 Nov 2015 16:26:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp References: <86ziy2xdt7.fsf@gmail.com> In-Reply-To: <86ziy2xdt7.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00522.txt.bz2 On 11/25/2015 04:07 PM, Yao Qi wrote: > 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? > Seems like a hack -- I don't see how that can make a difference. In both cases, we send \003 after 500ms. The test sets a software watchpoint, and resumes the target. That means the program will be constantly single-stepping, and gdb will be evaluating the watched expression at each single-step. I'd suspect that the problem is likely that while the program is stopped to evaluate the watched expression, something is calling target_terminal_ours, which restores handle_sigint as SIGINT handler. Then somehow you're unlucky to manage to ctrl-c at that exact time. The fix in that case is likely to be to call target_terminal_ours_for_output instead, which doesn't touch the SIGINT handler. Thanks, Pedro Alves