This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb.python/py-evthreads.exp: fix racy test (PR testsuite/12649)
- From: Marek Polacek <mpolacek at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 06 Jul 2011 14:09:22 +0200
- Subject: Re: [PATCH] gdb.python/py-evthreads.exp: fix racy test (PR testsuite/12649)
- References: <4E09E2C1.2020909@redhat.com> <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 {