Re: Regression for gdbserver [Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues]

["Maciej W. Rozycki" <macro@codesourcery.com>]

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