* [Bug gdb/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
@ 2023-05-04 8:25 ` vries at gcc dot gnu.org
2023-05-04 8:25 ` [Bug testsuite/30414] " vries at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2023-05-04 8:25 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #0)
> I haven't figured out how the test can get out of the gdb_test_multiple
> without a value for ubound.
I think this is what happens when hitting this clause:
...
-re ".*LBOUND = (\[^\r\n\]+)\r\n" {
set expected_lbound $expect_out(1,string)
if {!$found_prompt} {
exp_continue
}
}
...
when $found_prompt == 1.
I wonder whether this'll fix it:
...
diff --git a/gdb/testsuite/gdb.fortran/lbound-ubound.exp
b/gdb/testsuite/gdb.fortran/lbound-ubound.exp
index fced41f9fe3..31a3be11c3d 100644
--- a/gdb/testsuite/gdb.fortran/lbound-ubound.exp
+++ b/gdb/testsuite/gdb.fortran/lbound-ubound.exp
@@ -59,9 +59,7 @@ while { $test_count < 500 } {
-re ".*LBOUND = (\[^\r\n\]+)\r\n" {
set expected_lbound $expect_out(1,string)
- if {!$found_prompt} {
- exp_continue
- }
+ exp_continue
}
-re ".*UBOUND = (\[^\r\n\]+)\r\n" {
set expected_ubound $expect_out(1,string)
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
2023-05-04 8:25 ` [Bug gdb/30414] " vries at gcc dot gnu.org
@ 2023-05-04 8:25 ` vries at gcc dot gnu.org
2023-05-04 11:50 ` simon.marchi at polymtl dot ca
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2023-05-04 8:25 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|gdb |testsuite
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentatively setting component to testsuite.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
2023-05-04 8:25 ` [Bug gdb/30414] " vries at gcc dot gnu.org
2023-05-04 8:25 ` [Bug testsuite/30414] " vries at gcc dot gnu.org
@ 2023-05-04 11:50 ` simon.marchi at polymtl dot ca
2023-05-04 11:57 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: simon.marchi at polymtl dot ca @ 2023-05-04 11:50 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--- Comment #3 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Tom de Vries from comment #1)
> (In reply to Simon Marchi from comment #0)
> > I haven't figured out how the test can get out of the gdb_test_multiple
> > without a value for ubound.
>
> I think this is what happens when hitting this clause:
> ...
> -re ".*LBOUND = (\[^\r\n\]+)\r\n" {
> set expected_lbound $expect_out(1,string)
> if {!$found_prompt} {
> exp_continue
> }
> }
> ...
> when $found_prompt == 1.
>
> I wonder whether this'll fix it:
> ...
> diff --git a/gdb/testsuite/gdb.fortran/lbound-ubound.exp
> b/gdb/testsuite/gdb.fortran/lbound-ubound.exp
> index fced41f9fe3..31a3be11c3d 100644
> --- a/gdb/testsuite/gdb.fortran/lbound-ubound.exp
> +++ b/gdb/testsuite/gdb.fortran/lbound-ubound.exp
> @@ -59,9 +59,7 @@ while { $test_count < 500 } {
>
> -re ".*LBOUND = (\[^\r\n\]+)\r\n" {
> set expected_lbound $expect_out(1,string)
> - if {!$found_prompt} {
> - exp_continue
> - }
> + exp_continue
> }
> -re ".*UBOUND = (\[^\r\n\]+)\r\n" {
> set expected_ubound $expect_out(1,string)
> ...
Hmm it could be. The gdb_test_multiple reads from both the GDB output and the
inferior's output, so it is possible that there is a race here, that we read
GDB's prompt before we read the UBOUND line. I'm wondering if there is a way
to hack the test case to force this to happen.
But I'm not sure why the test case uses inferior I/O to print the expected
results. Could it instead place the expected results in some variables that
GDB would read, while stopped at the test breakpoint?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
` (2 preceding siblings ...)
2023-05-04 11:50 ` simon.marchi at polymtl dot ca
@ 2023-05-04 11:57 ` vries at gcc dot gnu.org
2023-05-04 12:05 ` simon.marchi at polymtl dot ca
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2023-05-04 11:57 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #3)
> Hmm it could be. The gdb_test_multiple reads from both the GDB output and
> the inferior's output, so it is possible that there is a race here, that we
> read GDB's prompt before we read the UBOUND line.
AFAIU, comment 0 shows the race happening:
...
(gdb) continue
Continuing.
Breakpoint 2, do_test (lb=..., ub=...) at
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
45 print *, "" ! Test Breakpoint
(gdb) Remote debugging from host ::1, port 37496
Expected GDB Output:
LBOUND = (-8, -10)
UBOUND = (-1, -2)
APB: Run a test here
APB: Expected lbound '(-8, -10)'
APB: Expected ubound ''
...
My understanding is that we see the order in which expect reads things, and in
this snippet the prompt comes before the UBOUND line.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
` (3 preceding siblings ...)
2023-05-04 11:57 ` vries at gcc dot gnu.org
@ 2023-05-04 12:05 ` simon.marchi at polymtl dot ca
2023-05-04 15:48 ` simon.marchi at polymtl dot ca
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: simon.marchi at polymtl dot ca @ 2023-05-04 12:05 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--- Comment #5 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Tom de Vries from comment #4)
> (In reply to Simon Marchi from comment #3)
> > Hmm it could be. The gdb_test_multiple reads from both the GDB output and
> > the inferior's output, so it is possible that there is a race here, that we
> > read GDB's prompt before we read the UBOUND line.
>
> AFAIU, comment 0 shows the race happening:
> ...
> (gdb) continue
> Continuing.
>
> Breakpoint 2, do_test (lb=..., ub=...) at
> /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/
> target_board/nati
> ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
> 45 print *, "" ! Test Breakpoint
> (gdb) Remote debugging from host ::1, port 37496
>
> Expected GDB Output:
>
> LBOUND = (-8, -10)
> UBOUND = (-1, -2)
> APB: Run a test here
> APB: Expected lbound '(-8, -10)'
> APB: Expected ubound ''
> ...
>
> My understanding is that we see the order in which expect reads things, and
> in this snippet the prompt comes before the UBOUND line.
Ah, yes. I wasn't able to decode the log, but now that you mention it, it
makes sense.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
` (4 preceding siblings ...)
2023-05-04 12:05 ` simon.marchi at polymtl dot ca
@ 2023-05-04 15:48 ` simon.marchi at polymtl dot ca
2023-05-18 17:22 ` cvs-commit at gcc dot gnu.org
2023-05-18 17:23 ` simon.marchi at polymtl dot ca
7 siblings, 0 replies; 9+ messages in thread
From: simon.marchi at polymtl dot ca @ 2023-05-04 15:48 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--- Comment #6 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Patch here:
https://inbox.sourceware.org/gdb-patches/20230504154829.34338-1-simon.marchi@efficios.com/T/#u
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
` (5 preceding siblings ...)
2023-05-04 15:48 ` simon.marchi at polymtl dot ca
@ 2023-05-18 17:22 ` cvs-commit at gcc dot gnu.org
2023-05-18 17:23 ` simon.marchi at polymtl dot ca
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-18 17:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2bf4cc2b92a45f9d857907aec3d14b5ffd9ebd2e
commit 2bf4cc2b92a45f9d857907aec3d14b5ffd9ebd2e
Author: Simon Marchi <simon.marchi@efficios.com>
Date: Thu May 4 11:28:48 2023 -0400
gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from
function parameters (PR 30414)
gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound
values by reading some output from the inferior. This is racy when
running on boards where the inferior I/O is on a separate TTY than
GDB's, such as native-gdbserver.
I sometimes see this behavior:
(gdb) continue
Continuing.
Breakpoint 2, do_test (lb=..., ub=...) at
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
45 print *, "" ! Test Breakpoint
(gdb) Remote debugging from host ::1, port 37496
Expected GDB Output:
LBOUND = (-8, -10)
UBOUND = (-1, -2)
APB: Run a test here
APB: Expected lbound '(-8, -10)'
APB: Expected ubound ''
What happened is that expect read the output from GDB before the output
from the inferior, triggering this gdb_test_multiple clause:
-re "$gdb_prompt $" {
set found_prompt true
if {$found_dealloc_breakpoint
|| ($expected_lbound != "" && $expected_ubound != "")} {
# We're done.
} else {
exp_continue
}
}
So it set found_prompt, but the gdb_test_multiple kept going because
found_dealloc_breakpoint is false (this is the flag indicating that the
test is finished) and we still don't have expected_lbound and
expected_ubound. Then, expect reads in the inferior I/O, triggering
this clause:
-re ".*LBOUND = (\[^\r\n\]+)\r\n" {
set expected_lbound $expect_out(1,string)
if {!$found_prompt} {
exp_continue
}
}
This sets expected_lbound, but since found_prompt is true, we don't do
exp_continue, and exit the gdb_test_multiple, without having an
expected_ubound.
Change the test to read the values from the lb and ub function
parameters instead. As far as I understand, this still exercises what
we want to test. These variables contain the return values of the
lbound and ubound functions as computed by the program. We'll use them
to check the return values of the lbound and ubound functions as
computed by GDB.
Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp
2023-05-03 1:53 [Bug gdb/30414] New: Random failure in gdb.fortran/lbound-ubound.exp simon.marchi at polymtl dot ca
` (6 preceding siblings ...)
2023-05-18 17:22 ` cvs-commit at gcc dot gnu.org
@ 2023-05-18 17:23 ` simon.marchi at polymtl dot ca
7 siblings, 0 replies; 9+ messages in thread
From: simon.marchi at polymtl dot ca @ 2023-05-18 17:23 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=30414
Simon Marchi <simon.marchi at polymtl dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #8 from Simon Marchi <simon.marchi at polymtl dot ca> ---
Fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread