From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17489 invoked by alias); 3 Dec 2015 17:19:24 -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 17478 invoked by uid 89); 3 Dec 2015 17:19:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Thu, 03 Dec 2015 17:19:22 +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 7AE33A1422; Thu, 3 Dec 2015 17:19:21 +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 tB3HJKYW006695; Thu, 3 Dec 2015 12:19:20 -0500 Message-ID: <56607997.5070209@redhat.com> Date: Thu, 03 Dec 2015 17:19: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 CC: gdb-patches@sourceware.org Subject: Re: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp References: <86ziy2xdt7.fsf@gmail.com> <5655E141.7030503@redhat.com> <86zixut7ju.fsf@gmail.com> <566039BF.5000207@redhat.com> <86oae7sbl8.fsf@gmail.com> In-Reply-To: <86oae7sbl8.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00057.txt.bz2 On 12/03/2015 05:09 PM, Yao Qi wrote: > Pedro Alves writes: > >> IMO, if the inferior is running and target_terminal_inferior is not in >> effect (*) then the ctrl-c should _not_ trigger a Python >> KeyboardInterrupt, but instead >> be sent to the target -- if the target is running and we're running some >> not-supposed-to-be-interactive Python unwinder code while processing >> some internal stop >> event, we know that the Python code will finish quickly and the target >> should stop >> for the SIGINT very soon. IOW, we treat the ctrl-c at exactly the >> wrong time as if >> it had been pressed a little sooner or later, outside Python. >> >> (*) - and it shouldn't, while an internal event is being processed. > > If I understand you correctly, ctrl-c shouldn't trigger a Python > KeyboardInterrupt, and we should fix it somewhere in GDB. Yes. > >> >> To handle the case of something going wrong and gdb getting stuck in a loop too >> long that the target's SIGINT takes forever to be processed, we could make gdb >> react to a _second_ (impatient) ctrl-c as "okay, I'm sick of waiting, >> please stop >> whatever you're doing". This is like how remote.c handles ctrl-c at exactly the >> wrong moment (while an internal event is processed) nowadays: >> >> https://sourceware.org/ml/gdb-patches/2015-08/msg00574.html > > I don't know how is this problem related to the second ctrl-c. It is > expected that single ctrl-c should interrupt the target, why do we need > the second ctrl-c in this case? > Say the Python code has a bug and ends up stuck in a loop and doesn't finish quickly what it's supposed to do (the target is never re-resumed and the SIGINT stop never processed). The user types ctrl-c, and, nothing happens. After a while, the user gets sick of waiting, and presses ctrl-c again. At this point, we could ask the user what do to, raise KeyboardInterrupt, Quit, etc. Thanks, Pedro Alves