Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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" {


             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