From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27951 invoked by alias); 1 Dec 2015 17:15:47 -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 27722 invoked by uid 89); 1 Dec 2015 17:15:46 -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-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Dec 2015 17:15:41 +0000 Received: by padhx2 with SMTP id hx2so11047235pad.1 for ; Tue, 01 Dec 2015 09:15:39 -0800 (PST) X-Received: by 10.98.68.209 with SMTP id m78mr80328939pfi.46.1448990139435; Tue, 01 Dec 2015 09:15:39 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id ud10sm1713105pab.27.2015.12.01.09.14.49 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 01 Dec 2015 09:15:08 -0800 (PST) From: Yao Qi To: Pedro Alves Cc: Yao Qi , 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> Date: Tue, 01 Dec 2015 17:15:00 -0000 In-Reply-To: <5655E141.7030503@redhat.com> (Pedro Alves's message of "Wed, 25 Nov 2015 16:26:41 +0000") Message-ID: <86zixut7ju.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00018.txt.bz2 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=3D, this_frame=3D, ca= che_ptr=3D0xd554f8) at /home/yao/SourceCode/gnu/gdb/git/gdb/python/py-unwin= d.c:608 #1 0x00000000006a10ae in frame_unwind_try_unwinder (this_frame=3Dthis_fra= me@entry=3D0xd554e0, this_cache=3Dthis_cache@entry=3D0xd554f8, unwinder=3D0= xecd540) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame-unwind.c:107 #2 0x00000000006a143f in frame_unwind_find_by_frame (this_frame=3Dthis_fr= ame@entry=3D0xd554e0, this_cache=3Dthis_cache@entry=3D0xd554f8) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame-unwind.c:163 #3 0x000000000069dc6b in compute_frame_id (fi=3D0xd554e0) at /home/yao/So= urceCode/gnu/gdb/git/gdb/frame.c:454 #4 get_prev_frame_if_no_cycle (this_frame=3Dthis_frame@entry=3D0xd55410) = at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1781 #5 0x000000000069fdb9 in get_prev_frame_always_1 (this_frame=3D0xd55410) = at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1955 #6 get_prev_frame_always (this_frame=3Dthis_frame@entry=3D0xd55410) at /h= ome/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1971 #7 0x00000000006a04b1 in get_prev_frame (this_frame=3Dthis_frame@entry=3D= 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. --=20 Yao (=E9=BD=90=E5=B0=A7)