From: Michael Snyder <msnyder@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com, fnasser@cygnus.com
Subject: Re: [rfa/testsuite] Make pthreads test more robust
Date: Fri, 28 Sep 2001 11:29:00 -0000 [thread overview]
Message-ID: <3BB4C175.42072289@cygnus.com> (raw)
In-Reply-To: <20010928114642.A913@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> I've been seeing about 90% failure rate for gdb.threads/pthreads.exp lately.
> The test which fails is always stopping threads with a control-c.
> I spent some time debugging this today; it seems that the course of events
> looks something like this:
> - send "continue\n"
> - wait
> - send "\003"
> - read back "Continuing."
> - timeout
>
> Note that, among other things, we never see "continue\n" echoed back to us,
> and yet gdb continues anyway. Obviously something is fishy in timing. We
> also do no reads between the continue and the \003. My best guess is that
> gdb does not get scheduled between the two sends; so waiting for the output
> of continue seems like a good idea.
>
> Also, I'm not entirely sure what 'after 1000 [ ... ]' is supposed to do, but
> it doesn't seem to delay by any measurable amount of time. Adding an
> additional sleep, so that the process has actually continued before we send
> the ^C, lets the test pass.
>
> Is this OK to commit? With it, the rest of pthreads.exp passes (except for
> the last test:
> break common_routine thread 4
> Breakpoint 6 at 0x8048666: file ../../../../src-hashtest/gdb/testsuite/gdb.threads/pthreads.c, line 50.
> (gdb) PASS: gdb.threads/pthreads.exp: set break at common_routine in thread 2
> continue
> Continuing.
> Cannot find thread 1024: generic error
> (gdb) FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2
> )
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.
> 2001-09-28 Daniel Jacobowitz <drow@mvista.com>
>
> * gdb.threads/pthreads.exp: Wait for output and delay
> before sending ^C.
>
> Index: pthreads.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/pthreads.exp,v
> retrieving revision 1.6
> diff -u -r1.6 pthreads.exp
> --- pthreads.exp 2001/06/06 18:34:53 1.6
> +++ pthreads.exp 2001/09/28 15:30:28
> @@ -248,6 +248,15 @@
>
> # Send a continue followed by ^C to the process to stop it.
> send_gdb "continue\n"
> + gdb_expect {
> + -re "Continuing." {
> + pass "Continue with all threads running"
> + }
> + timeout {
> + fail "Continue with all threads running (timeout)"
> + }
> + }
> + sleep 1
> set description "Stopped with a ^C"
> after 1000 [send_gdb "\003"]
> gdb_expect {
next prev parent reply other threads:[~2001-09-28 11:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-28 8:46 Daniel Jacobowitz
2001-09-28 11:29 ` Michael Snyder [this message]
2001-10-01 8:17 ` Fernando Nasser
2001-10-01 13:37 ` 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=3BB4C175.42072289@cygnus.com \
--to=msnyder@cygnus.com \
--cc=drow@mvista.com \
--cc=fnasser@cygnus.com \
--cc=gdb-patches@sources.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