Re: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp

[Yao Qi <qiyaoltc@gmail.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 (齐尧)