This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Regression for gdbserver [Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues]
On Tue, 22 May 2012, Jan Kratochvil wrote:
> On Tue, 22 May 2012 02:05:28 +0200, Maciej W. Rozycki wrote:
> > Applied now, thanks for the review.
>
> 272cb31d810a541dcc44f942fabb3167580b838e is the first bad commit
> commit 272cb31d810a541dcc44f942fabb3167580b838e
> Author: Maciej W. Rozycki <macro@linux-mips.org>
> Date: Mon May 21 23:50:25 2012 +0000
>
> * linux-low.c (linux_store_registers): Don't re-retrieve data
> with ptrace that has already been obtained from /proc. Always
> copy any data retrieved with ptrace to the buffer supplied.
>
> -PASS: gdb.mi/gdb701.exp: list children of fooPtr
> +FAIL: gdb.mi/gdb701.exp: list children of fooPtr
> -PASS: gdb.mi/mi2-var-child.exp: VT: list children of ptr2.*ptr.1_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: VT: list children of ptr2.*ptr.1_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: VT: create root varobj for v
> -PASS: gdb.mi/mi2-var-child.exp: VT: list children of v3
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3.x
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3.x
> -PASS: gdb.mi/mi2-var-child.exp: VT: list children of v3.1_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3.1_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3.1_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: VT: list children of v3.2_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3.2_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3.2_anonymous
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3.1_anonymous.a
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3.1_anonymous.a
> -PASS: gdb.mi/mi2-var-child.exp: path expression for v3.2_anonymous.b
> -PASS: gdb.mi/mi2-var-child.exp: expression for v3.2_anonymous.b
> +FAIL: gdb.mi/mi2-var-child.exp: VT: create root varobj for v
> +FAIL: gdb.mi/mi2-var-child.exp: VT: list children of v3
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3.x
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3.x
> +FAIL: gdb.mi/mi2-var-child.exp: VT: list children of v3.1_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3.1_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3.1_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: VT: list children of v3.2_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3.2_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3.2_anonymous
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3.1_anonymous.a
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3.1_anonymous.a
> +FAIL: gdb.mi/mi2-var-child.exp: path expression for v3.2_anonymous.b
> +FAIL: gdb.mi/mi2-var-child.exp: expression for v3.2_anonymous.b
> (many more, I did not list them all)
>
> 888-interpreter-exec console "set $pc=0x0"^M
> -888^done^M
> +=thread-group-exited,id="i1"^M
> +&"Remote connection closed\n"^M
> +888^error,msg="Remote connection closed"^M
> (gdb) ^M
> -PASS: gdb.mi/mi-cli.exp: -interpreter-exec console "set $pc=0x0"
> +FAIL: gdb.mi/mi-cli.exp: -interpreter-exec console "set $pc=0x0"
>
> -var-list-children fooPtr^M
> +=thread-group-exited,id="i1"^M
> ^done,numchild="3",children=[child={name="fooPtr.x",exp="x",numchild="0",type="int",thread-id="1"},child={name="fooPtr.y",exp="y",numchild="0",type="int",thread-id="1"},child={name="fooPtr.z",exp="z",numchild="0",type="int",thread-id="1"}],has_more="0"^M
> (gdb) ^M
> -PASS: gdb.mi/gdb701.exp: list children of fooPtr
> +FAIL: gdb.mi/gdb701.exp: list children of fooPtr
>
> -var-create v3 * v^M
> -^done,name="v3",numchild="3",value="{...}",type="struct {...}",thread-id="1",has_more="0"^M
> +^error,msg="-var-create: unable to create variable object"^M
> (gdb) ^M
> -PASS: gdb.mi/mi2-var-child.exp: VT: create root varobj for v
> +FAIL: gdb.mi/mi2-var-child.exp: VT: create root varobj for v
I don't have these failures in my test run, which target is that? Can
you check that these are not intermittent failures -- I recall at least
gdb.mi/mi2-var-child.exp to be somewhat unreliable (I don't recall
gdb.mi/gdb701.exp ever causing troubles though).
I have e.g.:
(gdb)
PASS: gdb.mi/mi-cli.exp: -interpreter-exec console "help set args"
Expecting: ^(888-interpreter-exec console "set \$pc=0x0"[
]+)?(888\^done[
]+[(]gdb[)]
[ ]*)
888-interpreter-exec console "set $pc=0x0"
888^done
(gdb)
PASS: gdb.mi/mi-cli.exp: -interpreter-exec console "set $pc=0x0"
testcase .../gdb/testsuite/gdb.mi/mi-cli.exp completed in 2 seconds
in a full mips-linux-gnu o32/EB test run that has just completed. I have
just run gdb.mi/gdb701.exp for all the eight multilibs I've been testing
recently and got 64 passes total and no failures too:
PASS: gdb.mi/gdb701.exp: breakpoint at main
PASS: gdb.mi/gdb701.exp: mi runto main
PASS: gdb.mi/gdb701.exp: step over "foo = 0"
PASS: gdb.mi/gdb701.exp: create fooPtr
PASS: gdb.mi/gdb701.exp: list children of fooPtr
PASS: gdb.mi/gdb701.exp: list children of fooPtr.x
PASS: gdb.mi/gdb701.exp: list children of fooPtr.y
PASS: gdb.mi/gdb701.exp: list children of fooPtr.z
Actually I checked the long runs too and all their eight multilibs have:
FAIL: gdb.mi/gdb701.exp: mi runto main (unknown output after running)
but all the other gdb.mi/gdb701.exp tests pass, so it looks to me this
test case is prone to intermittent failures as well.
The full log is like this:
(gdb)
220-exec-continue
220^running
*running,thread-id="all"
(gdb)
mi_expect_stop: expecting: \*stopped,reason="breakpoint-hit",disp="del",bkptno="[0-9]+",frame={addr="0x[0-9A-Fa-f]+",func="main",args=\[.*\],(?:file="[^
]*.*",fullname="(/[^\n]*/|\\\\[^\\]+\\[^\n]+\\|\\[^\\][^\n]*\\|[a-zA-Z]:[^\n]*\\).*",line="[0-9]+"|from=".*")},thread-id="[0-9]+",stopped-threads=[^
]*
(=thread-selected,id="[0-9]+"
|Breakpoint [0-9]+ at 0x[0-9A-Fa-f]+: file .*func-ptrs.c, line [0-9]+\.)*[(]gdb[)]
$
=library-loaded,id=".../el/lib/../lib64/libm.so.6",target-name=".../el/lib/../lib64/libm.so.6",host-name=".../el/lib/../lib64/libm.so.6",symbols-loaded="0",thread-group="i1"
=library-loaded,id=".../el/lib/../lib64/libc.so.6",target-name=".../el/lib/../lib64/libc.so.6",host-name=".../el/lib/../lib64/libc.so.6",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000120000a6c",func="main",file=".../gdb/testsuite/gdb.mi/gdb701.c",fullname=".../gdb/testsuite/gdb.mi/gdb701.c",line="13",times="1",original-location="main"}
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x0000000120000a6c",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffffb8b8"}],file=".../gdb/testsuite/gdb.mi/gdb701.c",fullname=".../gdb/testsuite/gdb.mi/gdb701.c",line="13"},thread-id="1",stopped-threads="all",core="0"
=breakpoint-deleted,id="1"
(gdb)
got =library-loaded,id=".../el/lib/../lib64/libm.so.6",target-name=".../el/lib/../lib64/libm.so.6",host-name=".../el/lib/../lib64/libm.so.6",symbols-loaded="0",thread-group="i1"
=library-loaded,id=".../el/lib/../lib64/libc.so.6",target-name=".../el/lib/../lib64/libc.so.6",host-name=".../el/lib/../lib64/libc.so.6",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000120000a6c",func="main",file=".../gdb/testsuite/gdb.mi/gdb701.c",fullname=".../gdb/testsuite/gdb.mi/gdb701.c",line="13",times="1",original-location="main"}
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x0000000120000a6c",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffffb8b8"}],file=".../gdb/testsuite/gdb.mi/gdb701.c",fullname=".../gdb/testsuite/gdb.mi/gdb701.c",line="13"},thread-id="1",stopped-threads="all",core="0"
=breakpoint-deleted,id="1"
(gdb)
FAIL: gdb.mi/gdb701.exp: mi runto main (unknown output after running)
which is weird as it looks that my newly-added gdb.base/func-ptrs.exp test
case (posted here recently) has overwritten a lib/mi-support.exp variable.
It shouldn't really happen, from it I infer the test cases are not run in
a subprocedure context each, but as a flat execution flow. That's
certainly begging for troubles and could explain some failures like the
above that only happen when the test suite is run as a whole, but not with
individual test cases.
I'll look into it.
Maciej