From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45288 invoked by alias); 3 Dec 2015 12:47:00 -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 45273 invoked by uid 89); 3 Dec 2015 12:46:59 -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 12:46:58 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1E0243298; Thu, 3 Dec 2015 12:46:57 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB3Ckt9F001027; Thu, 3 Dec 2015 07:46:56 -0500 Message-ID: <566039BF.5000207@redhat.com> Date: Thu, 03 Dec 2015 12:47: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> In-Reply-To: <86zixut7ju.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00044.txt.bz2 On 12/01/2015 05:14 PM, Yao Qi wrote: > Pedro Alves writes: > >> 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. > > The cause of this problem is the SIGINT is handled by python. > > As you said, program is being single-stepped constantly, and in each > stop, python unwinder sniffer is used, > > #0 pyuw_sniffer (self=, this_frame=, cache_ptr=0xd554f8) at /home/yao/SourceCode/gnu/gdb/git/gdb/python/py-unwind.c:608 > #1 0x00000000006a10ae in frame_unwind_try_unwinder (this_frame=this_frame@entry=0xd554e0, this_cache=this_cache@entry=0xd554f8, unwinder=0xecd540) > at /home/yao/SourceCode/gnu/gdb/git/gdb/frame-unwind.c:107 > #2 0x00000000006a143f in frame_unwind_find_by_frame (this_frame=this_frame@entry=0xd554e0, this_cache=this_cache@entry=0xd554f8) > at /home/yao/SourceCode/gnu/gdb/git/gdb/frame-unwind.c:163 > #3 0x000000000069dc6b in compute_frame_id (fi=0xd554e0) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:454 > #4 get_prev_frame_if_no_cycle (this_frame=this_frame@entry=0xd55410) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1781 > #5 0x000000000069fdb9 in get_prev_frame_always_1 (this_frame=0xd55410) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1955 > #6 get_prev_frame_always (this_frame=this_frame@entry=0xd55410) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1971 > #7 0x00000000006a04b1 in get_prev_frame (this_frame=this_frame@entry=0xd55410) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:2213 > > and the extension language is set, so GDB changes to cooperative SIGINT > handling by the extension language. See extension.c:set_active_ext_lang. > If ctrl-c is pressed at that time, it is reasonable to me that python > exception KeyboardInterrupt is thrown out. In the previous discussion > https://www.sourceware.org/ml/gdb-patches/2014-01/msg00106.html > > Tom Tromey wrote: >> The basic idea is that if some extension code is running, then C-c ought >> to interrupt that code in the way expected by programmers writing code >> in that language. > > As a GDB developer, I can understand that when python is running, Ctrl-c > should trigger KeyboardInterrupt, and when the inferior is running, > Ctrl-c should send interrupt sequence to the remote target. If we > accept this fact, we can fix test case, since output of > KeyboardInterrupt is also correct. However, as a GDB user, it is quite > confusing on the expected behavior for ctrl-c, which depends on the time > ctrl-c is pressed, but I don't have a good idea to fix it, because there > is no such clear boundary of GDB code and python code from both > developers' and users' point of view. 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. 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 Thanks, Pedro Alves