This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>
- Cc: gdb-patches at sources dot redhat dot com, msnyder at redhat dot com, jjohnstn at redhat dot com
- Date: Fri, 7 May 2004 02:14:22 -0400
- Subject: Re: [rfa/testsuite/threads] manythreads.exp: cancel outstanding after-blocks
- References: <20040507060902.DF1994B104@berman.michael-chastain.com>
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