From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sources.redhat.com
Cc: Michael Snyder <msnyder@redhat.com>
Subject: [rfa/threads test] Check for SIGINT handling in manythreads.exp
Date: Mon, 04 Apr 2005 04:21:00 -0000 [thread overview]
Message-ID: <20050404042131.GA8509@nevyn.them.org> (raw)
The intermittent failure of this test using LinuxThreads puzzled me for a
while. It looked like this:
(gdb) continue
Continuing.
[expect sends ^C]
(gdb) Quit
(gdb) FAIL:
Now where'd that prompt come from? Turns out using after for delays isn't
such a good idea. We lose inferior output while sleeping. Same thing
for "exec sleep 1". But if we use gdb_expect, we can see what's going on:
a second copy of the previous SIGINT arrived after the continue command.
So GDB was already stopped when the ^C was sent, thus the Quit message.
This patch updates the testcase so that the log shows what's going on, and
adds an explicit test that we don't get duplicate signals. With my previous
patch from today, the test passes.
OK?
--
Daniel Jacobowitz
CodeSourcery, LLC
2005-04-04 Daniel Jacobowitz <dan@codesourcery.com>
* gdb.threads/manythreads.exp: Use gdb_expect instead of after.
Add a test for duplicated SIGINTs.
Index: testsuite/gdb.threads/manythreads.exp
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/testsuite/gdb.threads/manythreads.exp,v
retrieving revision 1.2
diff -u -p -r1.2 manythreads.exp
--- testsuite/gdb.threads/manythreads.exp 3 Jun 2004 22:10:56 -0000 1.2
+++ testsuite/gdb.threads/manythreads.exp 4 Apr 2005 04:18:00 -0000
@@ -1,5 +1,5 @@
# manythreads.exp -- Expect script to test stopping many threads
-# Copyright (C) 2004 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -59,8 +59,11 @@ gdb_test_multiple "continue" "first cont
}
}
+# Wait one second. This is better than the TCL "after" command, because
+# we don't lose GDB's output while we do it.
+gdb_expect 1 { timeout { } }
+
# Send a Ctrl-C and verify that we can do info threads and continue
-after 1000
send_gdb "\003"
set message "stop threads 1"
gdb_test_multiple "" "stop threads 1" {
@@ -93,8 +96,35 @@ gdb_test_multiple "continue" "second con
}
}
+# Wait another second. If the program stops on its own, GDB has failed
+# to handle duplicate SIGINTs sent to multiple threads.
+set failed 0
+gdb_expect 1 {
+ -re "\\\[New \[^\]\]*\\\]\r\n" {
+ exp_continue -continue_timer
+ }
+ -re "\\\[\[^\]\]* exited\\\]\r\n" {
+ exp_continue -continue_timer
+ }
+ -re "Thread \[^\n\]* executing\r\n" {
+ exp_continue -continue_timer
+ }
+ -re "Program received signal SIGINT.*$gdb_prompt $" {
+ if { $failed == 0 } {
+ fail "check for duplicate SIGINT"
+ }
+ send_gdb "continue\n"
+ set failed 1
+ exp_continue
+ }
+ timeout {
+ if { $failed == 0 } {
+ pass "check for duplicate SIGINT"
+ }
+ }
+}
+
# Send another Ctrl-C and verify that we can do info threads and quit
-after 1000
send_gdb "\003"
set message "stop threads 2"
gdb_test_multiple "" "stop threads 2" {
next reply other threads:[~2005-04-04 4:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-04 4:21 Daniel Jacobowitz [this message]
2005-04-04 4:15 ` [rfa/linux] Make SIGINT handling more robust Daniel Jacobowitz
2005-04-04 4:17 ` Daniel Jacobowitz
2008-07-27 21:13 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050404042131.GA8509@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox