Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> That's a nice trick, I didn't know it.  But it's simpler to just make
> the stop synchronous... would you mind trying that instead?

Sure, I can do it that synchronously.  This fixes the problems with
print-threads.exp the same way.  I get more frequent gdb internal
errors when running this test with a synchronous sleep, but that's
good for a test script.

Tested again on native i686-pc-linux-gnu, red hat 8.0, group of 12
test runs before and after.

OK to commit?

Michael C

2004-05-07  Michael Chastain  <mec.gnu@mindspring.com>

	Fix PR gdb/1636.
	* gdb.threads/manythreads.exp: Change asynchronous 'after'
	calls to synchronous.

Index: gdb.threads/manythreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/manythreads.exp,v
retrieving revision 1.1
diff -c -3 -p -r1.1 manythreads.exp
*** gdb.threads/manythreads.exp	22 Apr 2004 22:19:40 -0000	1.1
--- gdb.threads/manythreads.exp	7 May 2004 12:41:39 -0000
*************** gdb_test_multiple "continue" "first cont
*** 60,66 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 60,67 ----
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
*************** gdb_test_multiple "continue" "second con
*** 93,99 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 94,101 ----
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {

Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

[Andrew Cagney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

Michael, this patch hasn't been reviewed.

Andrew
---  Begin Message  ---

From : mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
To : msnyder at redhat dot com
Cc : drow at mvista dot com, gdb-patches at sources dot redhat dot com,jjohnstn at redhat dot com
Date : Fri,  7 May 2004 08:46:25 -0400 (EDT)
Subject : Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks
Delivery-date : Fri, 07 May 2004 09:33:46 -0400
Envelope-to : cagney@gnu.org

Daniel Jacobowitz writes:
> That's a nice trick, I didn't know it.  But it's simpler to just make
> the stop synchronous... would you mind trying that instead?

Sure, I can do it that synchronously.  This fixes the problems with
print-threads.exp the same way.  I get more frequent gdb internal
errors when running this test with a synchronous sleep, but that's
good for a test script.

Tested again on native i686-pc-linux-gnu, red hat 8.0, group of 12
test runs before and after.

OK to commit?

Michael C

2004-05-07  Michael Chastain  <mec.gnu@mindspring.com>

	Fix PR gdb/1636.
	* gdb.threads/manythreads.exp: Change asynchronous 'after'
	calls to synchronous.

Index: gdb.threads/manythreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/manythreads.exp,v
retrieving revision 1.1
diff -c -3 -p -r1.1 manythreads.exp
*** gdb.threads/manythreads.exp	22 Apr 2004 22:19:40 -0000	1.1
--- gdb.threads/manythreads.exp	7 May 2004 12:41:39 -0000
*************** gdb_test_multiple "continue" "first cont
*** 60,66 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 60,67 ----
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
*************** gdb_test_multiple "continue" "second con
*** 93,99 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 94,101 ----
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {

---  End Message  ---

[rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

[Michael Elizabeth Chastain]

[Oops, how about a message body this time!]

This patch fixes PR gdb/1636, a problem in manythreads.exp.

  http://sources.redhat.com/gdb/bugs/1636
  manythreads.exp issues async ^C that spills onto next script

manythreads.exp creates some asynchronous blocks for sending ^C at a
later time.  This patch simply cancels the blocks before manythreads.exp
exits in case the blocks haven't executed yet.  This prevents the async
blocks from hanging around and sending their ^C during the middle of the
next script, print-threads.exp.

I don't know whether these blocks should be async at all, but I'm not
touching that part.  This just keeps print-threads.exp from barfing
during before-and-after runs that I do for any other work.

I tested this on native i686-pc-linux-gnu, red hat 8.0, with several
gcc's and binutils and both dwarf-2 and stabs+.  I did 12 test runs
before and after.  About 3-4 of the runs in each test group exhibit
internal errors in gdb which case manythreads.exp to FAIL.  I verified
that the next test script, print-threads.exp, was no longer clobbered by
this.

Okay to commit?

2004-05-07  Michael Chastain  <mec.gnu@mindspring.com>

	Fix PR gdb/1636.
	* gdb.threads/manythreads.exp: Cancel any outstanding after-blocks.

Index: gdb.threads/manythreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/manythreads.exp,v
retrieving revision 1.1
diff -c -3 -p -r1.1 manythreads.exp
*** gdb.threads/manythreads.exp	22 Apr 2004 22:19:40 -0000	1.1
--- gdb.threads/manythreads.exp	7 May 2004 05:59:44 -0000
*************** gdb_test_multiple "continue" "first cont
*** 60,66 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 60,66 ----
  }
  
  # Send a Ctrl-C and verify that we can do info threads and continue
! set after_id_1 [after 1000 {send_gdb "\003"}]
  set message "stop threads 1"
  gdb_test_multiple "" "stop threads 1" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
*************** gdb_test_multiple "continue" "second con
*** 93,99 ****
  }
  
  # 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" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
--- 93,99 ----
  }
  
  # Send another Ctrl-C and verify that we can do info threads and quit
! set after_id_2 [after 1000 {send_gdb "\003"}]
  set message "stop threads 2"
  gdb_test_multiple "" "stop threads 2" {
    -re "\\\[New \[^\]\]*\\\]\r\n" {
*************** gdb_test_multiple "" "stop threads 2" {
*** 109,114 ****
--- 109,118 ----
      pass "stop threads 2"
    }
  } 
+ 
+ # cancel any outstanding after-blocks
+ after cancel $after_id_1
+ after cancel $after_id_2
  
  gdb_test_multiple "quit" "GDB exits after stopping multithreaded program" {
      -re "The program is running.  Exit anyway\\? \\(y or n\\) $" {

Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

[Daniel Jacobowitz]

On Fri, May 07, 2004 at 02:09:02AM -0400, Michael Chastain wrote:
> [Oops, how about a message body this time!]
> 
> This patch fixes PR gdb/1636, a problem in manythreads.exp.
> 
>   http://sources.redhat.com/gdb/bugs/1636
>   manythreads.exp issues async ^C that spills onto next script
> 
> manythreads.exp creates some asynchronous blocks for sending ^C at a
> later time.  This patch simply cancels the blocks before manythreads.exp
> exits in case the blocks haven't executed yet.  This prevents the async
> blocks from hanging around and sending their ^C during the middle of the
> next script, print-threads.exp.
> 
> I don't know whether these blocks should be async at all, but I'm not
> touching that part.  This just keeps print-threads.exp from barfing
> during before-and-after runs that I do for any other work.
> 
> I tested this on native i686-pc-linux-gnu, red hat 8.0, with several
> gcc's and binutils and both dwarf-2 and stabs+.  I did 12 test runs
> before and after.  About 3-4 of the runs in each test group exhibit
> internal errors in gdb which case manythreads.exp to FAIL.  I verified
> that the next test script, print-threads.exp, was no longer clobbered by
> this.
> 
> Okay to commit?
> 
> 2004-05-07  Michael Chastain  <mec.gnu@mindspring.com>
> 
> 	Fix PR gdb/1636.
> 	* gdb.threads/manythreads.exp: Cancel any outstanding after-blocks.

That's a nice trick, I didn't know it.  But it's simpler to just make
the stop synchronous... would you mind trying that instead?


-- 
Daniel Jacobowitz

[rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks

[Michael Elizabeth Chastain]