This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/testsuite] Make pthreads test more robust
- To: Fernando Nasser <fnasser at redhat dot com>
- Subject: Re: [rfa/testsuite] Make pthreads test more robust
- From: Daniel Jacobowitz <drow at mvista dot com>
- Date: Mon, 1 Oct 2001 16:38:07 -0400
- Cc: Michael Snyder <msnyder at cygnus dot com>, gdb-patches at sources dot redhat dot com
- References: <20010928114642.A913@nevyn.them.org> <3BB4C175.42072289@cygnus.com> <3BB887DF.D4452C00@redhat.com>
On Mon, Oct 01, 2001 at 11:12:31AM -0400, Fernando Nasser wrote:
> (please see below)
>
>
> Michael Snyder wrote:
> > The patch looks sane. I'd like Fernando's blessing, but I'm inclined
> > to suggest checking it in and just watching out to see if it breaks
> > on any other platform.
> >
>
> I thought I had already responded to that, but I can't find the
> answer...
>
> I agree with Michael -- lets try. There is definitively a race
> condition
> in there. If GDB does not say continue in 1 sec. we send it a Cntl-C
> and
> I am not so sure what the output will look like if we send the Cntl-C
> before
> GDB says "Continuing".
>
> With your change we will be sure that the program is running before
> sending
> the interrupt request. I guess it is the right thing to do.
I agree; patch committed. If it breaks again, we can try harder :)
> P.S.: The "after" command schedules something to be done after a certain
> time.
> In this case, after a second (1000 milliseconds), a "\003" will be sent
> to GDB.
> So, we make it run and then interrupt it.
>
> P.S.2: I wonder if there isn't a second race condition between the 1 sec
> to
> interrupt and the timeout of gdb_expect...
That might be it. My failing tests looked like the interrupt was being
sent too soon, though, rather than not soon enough.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer