Message ID | 1615021.krJEU3LQPO@ralph.baldwin.cx |
---|---|
State | New, archived |
Headers |
Received: (qmail 116643 invoked by alias); 15 Nov 2017 20:11:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 116632 invoked by uid 89); 15 Nov 2017 20:11:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KB_WAM_FROM_NAME_SINGLEWORD, SPF_HELO_PASS, SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=Hx-languages-length:2533 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Nov 2017 20:11:52 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9C51A10A8BE; Wed, 15 Nov 2017 15:11:49 -0500 (EST) From: John Baldwin <jhb@freebsd.org> To: Yao Qi <qiyaoltc@gmail.com> Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3] Add a 'starti' command. Date: Wed, 15 Nov 2017 12:11:27 -0800 Message-ID: <1615021.krJEU3LQPO@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <86inerwm8t.fsf@gmail.com> References: <20170911220803.73819-1-jhb@FreeBSD.org> <86inerwm8t.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes |
Commit Message
John Baldwin
Nov. 15, 2017, 8:11 p.m. UTC
On Friday, November 03, 2017 01:00:18 PM Yao Qi wrote: > John Baldwin <jhb@FreeBSD.org> writes: > > > +# Continue to the start of main(). The constructor should have run so > > +# 'x' should be 1. > > + > > +gdb_breakpoint main > > +gdb_test_sequence "continue" "" { > > + "\\$2 = 1" > > + ".*Breakpoint .*main \\(\\) at .*starti.c.*" > > Here is a test failure, captured by buildbot, > https://sourceware.org/ml/gdb-testers/2017-q3/msg04381.html > > (gdb) gdb_expect_list pattern: /\$2 = 1/ > continue^M > Continuing.^M > $2 = 1^M > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > ^M > Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: ^M > main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > 29 return 0;^M > (gdb) gdb_expect_list pattern: // > FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > > Can you take a look? Hmm, so it seems the python exception adds a newline which throws the regex match off as 'main \(\)' is now on a second line. The 'start.exp' test only looks for the 'main' bit and not the preceding 'Breakpoint', so something like this instead? commit ec4df1376eee46840faa5857ed6fb497df2e7a69 Author: John Baldwin <jhb@FreeBSD.org> Date: Wed Nov 15 12:08:13 2017 -0800 Relax final regex in starti.exp test. Python exceptions from unwinders can interrupt the output between 'Breakpoint <n>' and the function name, so use a simpler regex that only looks for the function name and filename similar to the regex used in start.exp. gdb/testsuite/ChangeLog: * gdb.base/starti.exp ("continue" test): Loosen regex.
Comments
On 11/15/2017 08:11 PM, John Baldwin wrote: > On Friday, November 03, 2017 01:00:18 PM Yao Qi wrote: >> John Baldwin <jhb@FreeBSD.org> writes: >> >>> +# Continue to the start of main(). The constructor should have run so >>> +# 'x' should be 1. >>> + >>> +gdb_breakpoint main >>> +gdb_test_sequence "continue" "" { >>> + "\\$2 = 1" >>> + ".*Breakpoint .*main \\(\\) at .*starti.c.*" >> >> Here is a test failure, captured by buildbot, >> https://sourceware.org/ml/gdb-testers/2017-q3/msg04381.html >> >> (gdb) gdb_expect_list pattern: /\$2 = 1/ >> continue^M >> Continuing.^M >> $2 = 1^M >> gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ >> ^M >> Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: ^M >> main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M >> 29 return 0;^M >> (gdb) gdb_expect_list pattern: // >> FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) >> >> Can you take a look? > > Hmm, so it seems the python exception adds a newline which throws the regex > match off as 'main \(\)' is now on a second line. The 'start.exp' test > only looks for the 'main' bit and not the preceding 'Breakpoint', so > something like this instead? But is the Python exception expected? From Yao's earlier paste: (gdb) gdb_expect_list pattern: /\$2 = 1/ continue^M Continuing.^M $2 = 1^M gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ ^M Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: ^M main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M 29 return 0;^M (gdb) gdb_expect_list pattern: // FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) "Installation error" looks quite odd to me. Why did that happen? Thanks, Pedro Alves
On Wednesday, November 15, 2017 08:23:41 PM Pedro Alves wrote: > On 11/15/2017 08:11 PM, John Baldwin wrote: > > On Friday, November 03, 2017 01:00:18 PM Yao Qi wrote: > >> John Baldwin <jhb@FreeBSD.org> writes: > >> > >>> +# Continue to the start of main(). The constructor should have run so > >>> +# 'x' should be 1. > >>> + > >>> +gdb_breakpoint main > >>> +gdb_test_sequence "continue" "" { > >>> + "\\$2 = 1" > >>> + ".*Breakpoint .*main \\(\\) at .*starti.c.*" > >> > >> Here is a test failure, captured by buildbot, > >> https://sourceware.org/ml/gdb-testers/2017-q3/msg04381.html > >> > >> (gdb) gdb_expect_list pattern: /\$2 = 1/ > >> continue^M > >> Continuing.^M > >> $2 = 1^M > >> gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > >> ^M > >> Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: ^M > >> main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > >> 29 return 0;^M > >> (gdb) gdb_expect_list pattern: // > >> FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > >> > >> Can you take a look? > > > > Hmm, so it seems the python exception adds a newline which throws the regex > > match off as 'main \(\)' is now on a second line. The 'start.exp' test > > only looks for the 'main' bit and not the preceding 'Breakpoint', so > > something like this instead? > > But is the Python exception expected? From Yao's earlier paste: > > (gdb) gdb_expect_list pattern: /\$2 = 1/ > continue^M > Continuing.^M > $2 = 1^M > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > ^M > Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: ^M > main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > 29 return 0;^M > (gdb) gdb_expect_list pattern: // > FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > > "Installation error" looks quite odd to me. Why did that happen? That I don't know. I think I have seen similar exceptions in the past if the python scripts were not installed to the shared data directory but python was enabled via --with-python. I wouldn't expect a buildbot to be in that situation. I looked at some of the other failures referenced at the URL and found some other results I don't quite understand. For example, for Fedora-x86_64-m32, a test run from earlier today passed starti.exp without issues, but the test linked above failed differently: (gdb) gdb_expect_list pattern: /\$2 = 1/ continue Continuing. $2 = 1 gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ Breakpoint 1, main () at /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c:29 29 return 0; (gdb) gdb_expect_list pattern: // FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) testcase /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 10 seconds Here the 'Breakpoint' pattern should have matched and it appears that the implicit empty pattern used to match the prompt didn't match? Trying to test the patch I posted earlier today I had an odd failure where 'gdb_breakpoint main' failed, but only the first time I ran the test. The failure seemed to involve expect missing the line confirming the breakpoint was set. Ehen I tried to reproduce this all my other trials of running the modified test succeeded. It does look like the Fedora-i686 test from the link failed in this way, but the failure doesn't make sense to me. It FAILs the setting of the breakpoint before it tries to set the breakpoint: 0xf7fd5ad0 in _start () from /lib/ld-linux.so.2 (gdb) PASS: gdb.base/starti.exp: starti (gdb) FAIL: gdb.base/starti.exp: setting breakpoint at main gdb_expect_list pattern: /\$2 = 1/ break main Breakpoint 1 at 0x80483f9: file /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c, line 29. (gdb) FAIL: gdb.base/starti.exp: continue (pattern 1) gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ gdb_expect_list pattern: // testcase /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 0 seconds (Here it never runs "continue" after setting the breakpoint either, though "continue" is the action that has the \$2 = 1 pattern in its list of expected responses.)
Pedro Alves <palves@redhat.com> writes: > But is the Python exception expected? From Yao's earlier paste: > > (gdb) gdb_expect_list pattern: /\$2 = 1/ > continue^M > Continuing.^M > $2 = 1^M > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > ^M > Breakpoint 1, Python Exception <type 'exceptions.NameError'> > Installation error: gdb.execute_unwinders function is missing: ^M > main () at > /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > 29 return 0;^M > (gdb) gdb_expect_list pattern: // > FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > > "Installation error" looks quite odd to me. Why did that happen? Here is the log on another machine, (gdb) gdb_expect_list pattern: /\$2 = 1/ continue^M Continuing.^M $2 = 1^M ^M gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ Breakpoint 1, main () at /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c:29^M 29 return 0;^M (gdb) gdb_expect_list pattern: // FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) No python exception.
On 11/15/2017 11:31 PM, John Baldwin wrote: > On Wednesday, November 15, 2017 08:23:41 PM Pedro Alves wrote: >> On 11/15/2017 08:11 PM, John Baldwin wrote: >> "Installation error" looks quite odd to me. Why did that happen? > > That I don't know. I think I have seen similar exceptions in the past if the > python scripts were not installed to the shared data directory but python was > enabled via --with-python. I wouldn't expect a buildbot to be in that > situation. Yeah. I don't think we should make the testcase cope with that. > > I looked at some of the other failures referenced at the URL and found some > other results I don't quite understand. For example, for Fedora-x86_64-m32, > a test run from earlier today passed starti.exp without issues, but the test > linked above failed differently: > > (gdb) gdb_expect_list pattern: /\$2 = 1/ > continue > Continuing. > $2 = 1 > > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > Breakpoint 1, main () at /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c:29 > 29 return 0; > (gdb) gdb_expect_list pattern: // > FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > testcase /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 10 seconds > > Here the 'Breakpoint' pattern should have matched and it appears that the > implicit empty pattern used to match the prompt didn't match? > > Trying to test the patch I posted earlier today I had an odd failure where > 'gdb_breakpoint main' failed, but only the first time I ran the test. The > failure seemed to involve expect missing the line confirming the breakpoint > was set. Ehen I tried to reproduce this all my other trials of running the > modified test succeeded. It does look like the Fedora-i686 test from the > link failed in this way, but the failure doesn't make sense to me. It FAILs > the setting of the breakpoint before it tries to set the breakpoint: > > 0xf7fd5ad0 in _start () from /lib/ld-linux.so.2 > (gdb) PASS: gdb.base/starti.exp: starti > > (gdb) FAIL: gdb.base/starti.exp: setting breakpoint at main > gdb_expect_list pattern: /\$2 = 1/ > break main > Breakpoint 1 at 0x80483f9: file /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c, line 29. > (gdb) FAIL: gdb.base/starti.exp: continue (pattern 1) > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > gdb_expect_list pattern: // > testcase /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 0 seconds > > (Here it never runs "continue" after setting the breakpoint either, though > "continue" is the action that has the \$2 = 1 pattern in its list of > expected responses.) Sounds like the sort of trouble you'd get if an earlier "(gdb)" prompt was left in expect's buffer, somehow. Thanks, Pedro Alves
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index bb8dd7923d..601b43cde2 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,7 @@ +2017-11-15 John Baldwin <jhb@FreeBSD.org> + + * gdb.base/starti.exp ("continue" test): Loosen regex. + 2017-11-15 Simon Marchi <simon.marchi@ericsson.com> * gdb.tui/completionn.exp (test_tab_completion): Add space in diff --git a/gdb/testsuite/gdb.base/starti.exp b/gdb/testsuite/gdb.base/starti.exp index 98167ce5c7..78d092e5fd 100644 --- a/gdb/testsuite/gdb.base/starti.exp +++ b/gdb/testsuite/gdb.base/starti.exp @@ -47,5 +47,5 @@ gdb_test_sequence "" "starti" { gdb_breakpoint main gdb_test_sequence "continue" "" { "\\$2 = 1" - ".*Breakpoint .*main \\(\\) at .*starti.c.*" + "main \\(\\) at .*starti.c.*" }