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: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Wed, 25 Nov 2015 16:26:41 +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>
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