From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28765 invoked by alias); 22 May 2012 12:43:54 -0000 Received: (qmail 28542 invoked by uid 22791); 22 May 2012 12:43:51 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 12:43:36 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SWoR4-00076i-B1 from Maciej_Rozycki@mentor.com ; Tue, 22 May 2012 05:43:34 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 05:43:14 -0700 Received: from [172.30.0.105] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.1.289.1; Tue, 22 May 2012 13:43:32 +0100 Date: Tue, 22 May 2012 12:43:00 -0000 From: "Maciej W. Rozycki" To: Jan Kratochvil CC: Pedro Alves , Subject: Re: Regression for gdbserver [Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues] In-Reply-To: <20120522080321.GA18378@host2.jankratochvil.net> Message-ID: References: <4FB67E6D.2040406@redhat.com> <4FB6ACEF.2030600@redhat.com> <20120522080321.GA18378@host2.jankratochvil.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00817.txt.bz2 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 > 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