diff mbox

[v3] Add a 'starti' command.

Message ID 1615021.krJEU3LQPO@ralph.baldwin.cx
State New, archived
Headers

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

Pedro Alves Nov. 15, 2017, 8:23 p.m. UTC | #1 
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
John Baldwin Nov. 15, 2017, 11:31 p.m. UTC | #2 
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.)
Yao Qi Nov. 16, 2017, 9:55 a.m. UTC | #3 
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.
Pedro Alves Nov. 16, 2017, 10:53 a.m. UTC | #4 
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 mbox

Patch

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.*"
 }