Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Marek Polacek <mpolacek@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb.python/py-evthreads.exp: fix racy test (PR testsuite/12649)
Date: Wed, 06 Jul 2011 14:36:00 -0000	[thread overview]
Message-ID: <4E145072.4030704@redhat.com> (raw)
In-Reply-To: <20110628155107.GL20676@adacore.com>

On 06/28/2011 05:51 PM, Joel Brobecker wrote:
> I'm also surprised to see some uses of gdb_expect in gdb.python.
> I wonder if we could replace them with uses of gdb_test_multiple
> (that would be a separate patch)...

Hmm, after a few days of struggling with converting gdb_expect to 
gdb_test_multiple, I don't think that's The Right Thing anymore.
The issue is that with send_gdb+gdb_expect we always get the same
sequence--e.g., at the "next" test case, we get:

next^M
event type: continue^M
thread num: 1^M
[New Thread 0x7ffff7fe5710 (LWP 1364)]^M
event type: continue^M
thread num: 1^M
47        pthread_create (&thread3_id, NULL, thread3, NULL);^M
event type: stop^M
event type: stop^M
(gdb) ^M
Breakpoint 2, thread2 (d=0x0) at ./gdb.python/py-evthreads.c:39^M
39        int count2 = 0;^M 
event type: stop^M
event type: stop^M
stop reason: breakpoint^M
breakpoint number: 2^M
thread num: 2Quitting ...

However, with gdb_test_multiple, we sometimes get:

next^M
event type: continue^M
thread num: 1^M
[New Thread 0x7ffff7fe5710 (LWP 31327)]^M
event type: continue^M
thread num: 1^M
^M
Breakpoint 2, thread2 (d=0x0) at ./gdb.python/py-evthreads.c:39^M
39        int count2 = 0;^M 
event type: stop^M
event type: stop^M
stop reason: breakpointQuitting ...

and some other time (and this fails):

next^M
event type: continue^M
thread num: 1^M
[New Thread 0x7ffff7fe5710 (LWP 31212)]^M
event type: continue^M
thread num: 1^M
47        pthread_create (&thread3_id, NULL, thread3, NULL);^M
event type: stop^M
event type: stop^M
(gdb) FAIL: gdb.python/py-evthreads.exp: reached breakpoint 2
Quitting ...

I don't understand why the gdb_test_multiple is non-deterministics :(.


I thus propose this simple patch to avoid race (basically the same as before, just
one extra space more).  At least, for now.
Tested with read{,1}.  OK to commit?  Thanks.

2011-07-06  Marek Polacek  <mpolacek@redhat.com>

	* gdb.python/py-evthreads.exp: Fix race by adding an anchor to match
	the whole output.

--- gdb/gdb/testsuite/gdb.python/py-evthreads.exp.mp	2011-06-22 15:14:07.869452151 +0200
+++ gdb/gdb/testsuite/gdb.python/py-evthreads.exp	2011-07-06 13:57:08.651591506 +0200
@@ -86,7 +86,7 @@ gdb_expect {
 send_gdb "continue&\n"
 gdb_expect {
     -re ".*event type: continue.*
-.*thread num: 1.*" {
+.*thread num: 1.*\r\n$gdb_prompt " {
         pass "continue thread 1"
     }
     timeout {


  parent reply	other threads:[~2011-07-06 12:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28 14:19 Marek Polacek
2011-06-28 15:51 ` Joel Brobecker
2011-06-30 10:26   ` Marek Polacek
2011-07-06 17:21     ` Jan Kratochvil
2011-07-06 17:32       ` Joel Brobecker
2011-07-06 17:57         ` Marek Polacek
2011-07-06 19:53           ` Jan Kratochvil
2011-07-06 22:06             ` Marek Polacek
2011-07-06 14:36   ` Marek Polacek [this message]
2011-07-06 14:51     ` Joel Brobecker
2011-07-06 15:46       ` Marek Polacek

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=4E145072.4030704@redhat.com \
    --to=mpolacek@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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