This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 25 Nov 2015 16:07:48 +0000
- Subject: exceptions.KeyboardInterrupt is thrown in gdb.base/random-signal.exp
- Authentication-results: sourceware.org; auth=none
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?
--
Yao (éå)
diff --git a/gdb/testsuite/gdb.base/random-signal.exp b/gdb/testsuite/gdb.base/random-signal.exp
index 566668a..59c8f5b 100644
--- a/gdb/testsuite/gdb.base/random-signal.exp
+++ b/gdb/testsuite/gdb.base/random-signal.exp
@@ -38,5 +38,6 @@ gdb_test_multiple "continue" "continue" {
# 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 500
+send_gdb "\003"