[PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

[PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

[Tom de Vries]

Hi,

The test-case gdb.dwarf2/locexpr-data-member-location.exp currently fails like
this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: : spawn id exp9 not open
    while executing
"expect {
-i exp9 -timeout 10
            -re "Quit this debugging session\\? \\(y or n\\) $" {
                send_gdb "n\n" answer
                incr count
            }
            -re "Create ..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp9 not open
ERROR: Could not resync from internal error (timeout)
...
and takes 1 minute to run.

The long running time is caused by the timeout of 60 in gdb_run_cmd.

Avoid this by simplify the test-case to trigger the same assert using the file
command instead.

Then fix the:
...
ERROR: : spawn id exp9 not open
...
by handling eof in gdb_internal_error_resync.

Finally, mark the FAIL as KFAIL, such that we end up with:
...
KFAIL: gdb.dwarf2/locexpr-data-member-location.exp: Discard file \
  (GDB internal error) (PRMS: gdb/28030)
ERROR: Could not resync from internal error (eof)
...
and a running time of 2 seconds.

Tested on x86_64-linux.

Any comments?

Thanks,
- Tom

[gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

---
 .../gdb.dwarf2/locexpr-data-member-location.exp    | 23 ++++++++++++++++------
 gdb/testsuite/lib/gdb.exp                          |  4 ++++
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
index 1f70e6a34bd..9423132e775 100644
--- a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
+++ b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
@@ -40,7 +40,7 @@
 #    purging of shared objects.
 #
 # 3) After performing some simple gdb commands, the program is
-#    run again.  In the course of running the objfile destructor
+#    discarded.  In the course of running the objfile destructor
 #    associated with the shared object, values are preserved
 #    along with their types.  As noted earlier, it was during
 #    the recursive type copy that the bug was observed.
@@ -342,8 +342,19 @@ gdb_test "step" "bar \\(.*" "step into bar"
 
 # We don't want a clean restart here since that will be too clean.
 # The original reproducer for PR28030 set a breakpoint in the shared
-# library and then restarted via "run".  The command below does roughly
-# the same thing.  It's at this step that an internal error would
-# occur for PR28030.  The "message" argument tells runto to turn on
-# the printing of PASSes while runto is doing its job.
-runto "bar" message
+# library and then restarted via "run".  The command below is more minimal:
+# it discards executable file and symbol table.  It's at the latter step
+# that an internal error would occur for PR28030.
+
+# Avoid questions from the file command about:
+# - Are you sure you want to change the file (y or n) ?
+# - Discard symbol table from <file> (y or n) ?
+gdb_test_no_output "set confirm off"
+
+# Tell internal-error how to behave, otherwise "set confirm off" will trigger
+# generation of core file.
+gdb_test_no_output "maint set internal-error quit no"
+gdb_test_no_output "maint set internal-error corefile no"
+
+setup_kfail gdb/28030 *-*-*
+gdb_test "file" "No executable file now\\." "Discard file"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 00336bd588e..cdda51529fb 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -770,6 +770,10 @@ proc gdb_internal_error_resync {} {
 		perror "Could not resync from internal error (timeout)"
 		return 0
 	    }
+	    eof {
+		perror "Could not resync from internal error (eof)"
+		return 0
+	    }
 	}
     }
     perror "Could not resync from internal error (resync count exceeded)"

[committed][gdb/testsuite] Handle eof in gdb_internal_error_resync

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

[ was: Re: [PATCH][gdb/testsuite] Simplify
gdb.dwarf2/locexpr-data-member-location.exp ]

On 9/5/21 8:39 AM, Tom de Vries wrote:
> Then fix the:
> ...
> ERROR: : spawn id exp9 not open
> ...
> by handling eof in gdb_internal_error_resync.

I've fixed this in a separate patch.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Handle-eof-in-gdb_internal_error_resync.patch --]
[-- Type: text/x-patch, Size: 1533 bytes --]

[gdb/testsuite] Handle eof in gdb_internal_error_resync

Before commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: : spawn id exp9 not open
    while executing
"expect {
-i exp9 -timeout 10
            -re "Quit this debugging session\\? \\(y or n\\) $" {
                send_gdb "n\n" answer
                incr count
            }
            -re "Create ..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp9 not open
ERROR: Could not resync from internal error (timeout)
...

Fix the:
...
ERROR: : spawn id exp9 not open
...
by handling eof in gdb_internal_error_resync, such that we have instead:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: Could not resync from internal error (eof)
...

Tested on x86_64-linux.

---
 gdb/testsuite/lib/gdb.exp | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 00336bd588e..cdda51529fb 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -770,6 +770,10 @@ proc gdb_internal_error_resync {} {
 		perror "Could not resync from internal error (timeout)"
 		return 0
 	    }
+	    eof {
+		perror "Could not resync from internal error (eof)"
+		return 0
+	    }
 	}
     }
     perror "Could not resync from internal error (resync count exceeded)"

[committed][gdb/testsuite] Handle internal-error in gdb_run_cmd

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

[ was: Re: [PATCH][gdb/testsuite] Simplify
gdb.dwarf2/locexpr-data-member-location.exp ]

On 9/5/21 8:39 AM, Tom de Vries wrote:
> The test-case gdb.dwarf2/locexpr-data-member-location.exp currently fails like
> this:
> ...
> ...
> and takes 1 minute to run.

I've fixed this in a separate patch.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Handle-internal-error-in-gdb_run_cmd.patch --]
[-- Type: text/x-patch, Size: 1591 bytes --]

[gdb/testsuite] Handle internal-error in gdb_run_cmd

When reverting commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: Could not resync from internal error (eof)
...
and takes 1 minute to run.

The long running time is caused by running into a timeout in gdb_run_cmd, at
this point:
...
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
  Unexpected type field location kind: 4^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n)
...

Fix this by detecting the internal-error in gdb_run_cmd.  We don't handle it
in gdb_run_cmd, but stash the gdb output back into the buffer using
-notransfer, and let the caller proc runto deal with it.

After the fix, the test-case just takes 2 seconds.

Tested on x86_64-linux.

---
 gdb/testsuite/lib/gdb.exp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index cdda51529fb..d99e8360808 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -408,6 +408,9 @@ proc gdb_run_cmd { {inferior_args {}} } {
 	-notransfer -re "$gdb_prompt $" {
 	    # There is no more input expected.
 	}
+	-notransfer -re "A problem internal to GDB has been detected" {
+	    # Let caller handle this.
+	}
     }
 
     return 0

[committed][gdb/testsuite] Handle internal-error in gdb_unload

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

[ was: Re: [PATCH][gdb/testsuite] Simplify
gdb.dwarf2/locexpr-data-member-location.exp ]

On 9/5/21 8:39 AM, Tom de Vries wrote:
> +# Avoid questions from the file command about:
> +# - Are you sure you want to change the file (y or n) ?
> +# - Discard symbol table from <file> (y or n) ?
> +gdb_test_no_output "set confirm off"
> +
> +# Tell internal-error how to behave, otherwise "set confirm off" will trigger
> +# generation of core file.
> +gdb_test_no_output "maint set internal-error quit no"
> +gdb_test_no_output "maint set internal-error corefile no"
> +
> +setup_kfail gdb/28030 *-*-*
> +gdb_test "file" "No executable file now\\." "Discard file"

I realized that we have gdb_unload for this, which handles the file
command questions.  But it's missing the internal-error handling.

I've fixed this in a separate patch.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Handle-internal-error-in-gdb_unload.patch --]
[-- Type: text/x-patch, Size: 1147 bytes --]

[gdb/testsuite] Handle internal-error in gdb_unload

When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar"
to trigger the internal-error in test-case
gdb.dwarf2/locexpr-data-member-location.exp, we run into:
...
ERROR: couldn't unload file in $gdb (timeout).
...
and the test-case takes about 1 minute.

Fix this by handling internal-error in gdb_unload, such that we have:
...
ERROR: Couldn't unload file in $gdb (GDB internal error).
ERROR: Could not resync from internal error (eof)
...
within 2 seconds.

Tested on x86_64-linux.

---
 gdb/testsuite/lib/gdb.exp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index d99e8360808..ff19760bac4 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -235,6 +235,11 @@ proc gdb_unload {} {
 	    exp_continue
 	}
 	-re "$gdb_prompt $" {}
+	-re "A problem internal to GDB has been detected" {
+	    perror "Couldn't unload file in $GDB (GDB internal error)."
+	    gdb_internal_error_resync
+	    return -1
+	}
 	timeout {
 	    perror "couldn't unload file in $GDB (timeout)."
 	    return -1

Re: [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

On 9/5/21 8:39 AM, Tom de Vries wrote:
> Avoid this by simplify the test-case to trigger the same assert using the file
> command instead.

FTR, after the other commits this is what remains.

At this point, I don't see a pressing reason for why this should be
committed.  But perhaps somebody else does.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Simplify-gdb.dwarf2-locexpr-data-member-location.exp.patch --]
[-- Type: text/x-patch, Size: 1878 bytes --]

[gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

When reverting commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp runs into an internal-error.

Simplify the test-case by triggering the internal-error using gdb_unload
instead of runto "bar".

Tested on x86_64-linux.

---
 gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
index 1f70e6a34bd..98f9270d7bb 100644
--- a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
+++ b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
@@ -40,7 +40,7 @@
 #    purging of shared objects.
 #
 # 3) After performing some simple gdb commands, the program is
-#    run again.  In the course of running the objfile destructor
+#    discarded.  In the course of running the objfile destructor
 #    associated with the shared object, values are preserved
 #    along with their types.  As noted earlier, it was during
 #    the recursive type copy that the bug was observed.
@@ -342,8 +342,7 @@ gdb_test "step" "bar \\(.*" "step into bar"
 
 # We don't want a clean restart here since that will be too clean.
 # The original reproducer for PR28030 set a breakpoint in the shared
-# library and then restarted via "run".  The command below does roughly
-# the same thing.  It's at this step that an internal error would
-# occur for PR28030.  The "message" argument tells runto to turn on
-# the printing of PASSes while runto is doing its job.
-runto "bar" message
+# library and then restarted via "run".  The command below is more minimal:
+# it discards executable file and symbol table.  It's at the latter step
+# that an internal error would occur for PR28030.
+gdb_unload

Re: [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp

[Simon Marchi]

On 2021-09-07 4:52 a.m., Tom de Vries wrote:
> On 9/5/21 8:39 AM, Tom de Vries wrote:
>> Avoid this by simplify the test-case to trigger the same assert using the file
>> command instead.
> 
> FTR, after the other commits this is what remains.
> 
> At this point, I don't see a pressing reason for why this should be
> committed.  But perhaps somebody else does.
> 
> Thanks,
> - Tom
> 

Well, we shouldn't have to add a kfail, the problem is that the test has
been pushed without the fix:

  https://sourceware.org/pipermail/gdb-patches/2021-August/181771.html

Simon