* [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp
@ 2021-09-05 6:39 Tom de Vries
2021-09-06 15:48 ` [committed][gdb/testsuite] Handle eof in gdb_internal_error_resync Tom de Vries
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Tom de Vries @ 2021-09-05 6:39 UTC (permalink / raw)
To: gdb-patches
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)"
^ permalink raw reply [flat|nested] 6+ messages in thread
* [committed][gdb/testsuite] Handle eof in gdb_internal_error_resync
2021-09-05 6:39 [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
@ 2021-09-06 15:48 ` Tom de Vries
2021-09-06 23:28 ` [committed][gdb/testsuite] Handle internal-error in gdb_run_cmd Tom de Vries
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Tom de Vries @ 2021-09-06 15:48 UTC (permalink / raw)
To: gdb-patches
[-- 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)"
^ permalink raw reply [flat|nested] 6+ messages in thread
* [committed][gdb/testsuite] Handle internal-error in gdb_run_cmd
2021-09-05 6:39 [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
2021-09-06 15:48 ` [committed][gdb/testsuite] Handle eof in gdb_internal_error_resync Tom de Vries
@ 2021-09-06 23:28 ` Tom de Vries
2021-09-07 8:21 ` [committed][gdb/testsuite] Handle internal-error in gdb_unload Tom de Vries
2021-09-07 8:52 ` [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
3 siblings, 0 replies; 6+ messages in thread
From: Tom de Vries @ 2021-09-06 23:28 UTC (permalink / raw)
To: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [committed][gdb/testsuite] Handle internal-error in gdb_unload
2021-09-05 6:39 [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
2021-09-06 15:48 ` [committed][gdb/testsuite] Handle eof in gdb_internal_error_resync Tom de Vries
2021-09-06 23:28 ` [committed][gdb/testsuite] Handle internal-error in gdb_run_cmd Tom de Vries
@ 2021-09-07 8:21 ` Tom de Vries
2021-09-07 8:52 ` [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
3 siblings, 0 replies; 6+ messages in thread
From: Tom de Vries @ 2021-09-07 8:21 UTC (permalink / raw)
To: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp
2021-09-05 6:39 [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
` (2 preceding siblings ...)
2021-09-07 8:21 ` [committed][gdb/testsuite] Handle internal-error in gdb_unload Tom de Vries
@ 2021-09-07 8:52 ` Tom de Vries
2021-09-08 0:34 ` Simon Marchi
3 siblings, 1 reply; 6+ messages in thread
From: Tom de Vries @ 2021-09-07 8:52 UTC (permalink / raw)
To: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-08 0:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-05 6:39 [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
2021-09-06 15:48 ` [committed][gdb/testsuite] Handle eof in gdb_internal_error_resync Tom de Vries
2021-09-06 23:28 ` [committed][gdb/testsuite] Handle internal-error in gdb_run_cmd Tom de Vries
2021-09-07 8:21 ` [committed][gdb/testsuite] Handle internal-error in gdb_unload Tom de Vries
2021-09-07 8:52 ` [PATCH][gdb/testsuite] Simplify gdb.dwarf2/locexpr-data-member-location.exp Tom de Vries
2021-09-08 0:34 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).