This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Tue, 01 Dec 2015 17:14:45 +0000
- Subject: Re: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp
- Authentication-results: sourceware.org; auth=none
- References: <86ziy2xdt7 dot fsf at gmail dot com> <5655E141 dot 7030503 at redhat dot com>
Pedro Alves <palves@redhat.com> 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=<optimised out>, this_frame=<optimised out>, 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.
--
Yao (éå)