From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 268EB3858C78; Thu, 4 May 2023 11:50:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 268EB3858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1683201024; bh=Dv8BiLqgbofC65y93NaWEw7DYX4Yeaj2MigQNh1wVYQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YDcqVPPWyGI+Gs29BE/0UBIlvarz2yDX4YYRrR6hZA4Zv1XSeRe7TcTC827KmNk36 bGLO/u5wLrfy7MjxKx9lPmgcX8vmP0eigAMoZJELpQGjFEbdcnLOXXZuIiguFGC8hr 5dcdQ+wpsQooAwP0/4ww8EJVsjVvYG94/fPOm2rQ= From: "simon.marchi at polymtl dot ca" To: gdb-prs@sourceware.org Subject: [Bug testsuite/30414] Random failure in gdb.fortran/lbound-ubound.exp Date: Thu, 04 May 2023 11:50:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simon.marchi at polymtl dot ca X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30414 --- Comment #3 from Simon Marchi --- (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. >=20 > I think this is what happens when hitting this clause: > ... > -re ".*LBOUND =3D (\[^\r\n\]+)\r\n" { > set expected_lbound $expect_out(1,string) > if {!$found_prompt} { > exp_continue > } > } > ... > when $found_prompt =3D=3D 1. >=20 > 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 } { >=20=20 > -re ".*LBOUND =3D (\[^\r\n\]+)\r\n" { > set expected_lbound $expect_out(1,string) > - if {!$found_prompt} { > - exp_continue > - } > + exp_continue > } > -re ".*UBOUND =3D (\[^\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 w= ay 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? --=20 You are receiving this mail because: You are on the CC list for the bug.=