From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp
Date: Tue, 16 Jan 2024 00:18:01 +0100 [thread overview]
Message-ID: <20240115231801.28434-1-tdevries@suse.de> (raw)
With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into:
...
(gdb) attach 7773^M
Attaching to program: attach-many-short-lived-threads, process 7773^M
Cannot attach to lwp 7776: Operation not permitted (1)^M
(gdb) PASS: $exp: iter 1: attach
info threads^M
No threads.^M
(gdb) PASS: $exp: iter 1: no new threads
set breakpoint always-inserted on^M
(gdb) PASS: $exp: iter 1: set breakpoint always-inserted on
break break_fn^M
Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M
(gdb) PASS: $exp: iter 1: break break_fn
continue^M
The program is not being run.^M
(gdb) FAIL: $exp: iter 1: break at break_fn: 1 \
(the program is no longer running)
...
There's some code in the test-case dealing with a similar warning:
...
-re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
...
But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be
traced"), the warning has been changed into an error.
Fix the FAIL by updating the test-case to expect an error instead of a
warning.
Tested on x86_64-linux.
---
.../gdb.threads/attach-many-short-lived-threads.exp | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp b/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp
index 3fdadf9827f..6bee0ad2e2c 100644
--- a/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp
+++ b/gdb/testsuite/gdb.threads/attach-many-short-lived-threads.exp
@@ -74,7 +74,7 @@ proc test {} {
# Seen when "set debug libthread_db" is on.
exp_continue
}
- -re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
+ -re "Cannot attach to lwp $decimal: Operation not permitted" {
# On Linux, PTRACE_ATTACH sometimes fails with
# EPERM, even though /proc/PID/status indicates
# the thread is running.
@@ -96,6 +96,10 @@ proc test {} {
}
}
+ if { $eperm } {
+ continue
+ }
+
# Sleep a bit and try updating the thread list. We should
# know about all threads already at this point. If we see
# "New Thread" or similar being output, then "attach" is
base-commit: f1870e2fadd400ff288da388497d50fdf7a5f2d5
--
2.35.3
next reply other threads:[~2024-01-15 23:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 23:18 Tom de Vries [this message]
2024-01-19 16:27 ` Tom Tromey
2024-01-24 18:51 ` Carl Love
2024-01-24 20:47 ` Carl Love
2024-01-26 16:13 ` Carl Love
2024-01-29 17:04 ` Tom Tromey
2024-01-29 18:13 ` Carl Love
2024-02-06 19:03 ` Carl Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240115231801.28434-1-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).