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

[Pedro Alves <palves@redhat.com>]

On 11/25/2015 04:07 PM, Yao Qi wrote:
> Hi,
> I am fixing a fail in gdb.base/random-signal.exp like this,
> 
> Continuing.^M
> PASS: gdb.base/random-signal.exp: continue
> ^CPython Exception <type 'exceptions.KeyboardInterrupt'> <type 'exceptions.KeyboardInterrupt'>: ^M
> FAIL: gdb.base/random-signal.exp: stop with control-c (timeout)
> 
> I only see this fail out of 15~20 runs each time.  Is it because GDB
> received SIGINT before async_handle_remote_sigint is installed?  so
> handle_sigint is still the SIGINT handler, set_quit_flag will call
> python stuff, and KeyboardInterrupt is raised as a result.
> 
> In the test, we've already been aware of that the signal handler isn't
> ready, so "Continuing" is consumed and ctrl-c is delayed in 500ms.
> 
> # For this to work we must be sure to consume the "Continuing."
> # message first, or GDB's signal handler may not be in place.
> after 500 {send_gdb "\003"}
> 
> After I read the tcl manul about "after", I feel the usage of "after"
> above isn't 100% correct.  As the manual says, the "after" command
> returns immediately, and the tcl command {send_gdb "\003"} will be
> executed 500 ms later.  It is an asynchronous flavour, but what we want is
> a synchronous operation, like this,
> 
> after 500
> send_gdb "\003"
> 
> with this change, I don't see the timeout fail again.  Is it a fix or a
> hack?
> 

Seems like a hack -- I don't see how that can make a difference.  In both
cases, we send \003 after 500ms.

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.

Thanks,
Pedro Alves