public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@arm.com>
To: Tom Tromey <tromey@adacore.com>
Cc: Tom Tromey via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/3] Fix "attach" infinite loop
Date: Mon, 18 Dec 2023 15:10:48 +0000	[thread overview]
Message-ID: <784a29ba-62ff-4518-9eca-ec20710a7581@arm.com> (raw)
In-Reply-To: <87msu74m7z.fsf@tromey.com>

On 12/18/23 14:30, Tom Tromey wrote:
> Luis> Attaching to program: /binutils-gdb-arm64-focal/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads, process 1545611
> Luis> Cannot attach to lwp 1609323: Operation not permitted (1)
> 
> Luis> Are we missing XFAIL-ing the test when we see the ptrace attach failure?
> 
> I see this in the test case:
> 
>     -re "warning: 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.
>         set eperm 1
>         exp_continue
>     }
> 
> However, this changed from a warning to an error.

Ah, I failed to spot that.

> 
> Could you try removing the 'warning: ' text and see if that helps?  It
> seems like it should issue an xfail instead.

I played with it for a bit, and it seems the testcase is somewhat broken.

It seems to assume everything is OK if it sees the message "Attaching to program: .*", which explains
the PASS we get from the above test.

If we ever see the EPERM error, we will set the eperm variable, but it will not matter, because the
matching for the attachment message will gobble things all the way to the gdb prompt, and will issue
a PASS, resuming the test (assuming there are live threads) and failing.

I think the testcase needs a bit of a rework to bail out if we fail to attach to the process. I'll
give it a go since it reproduces easily for me.

  reply	other threads:[~2023-12-18 15:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 17:56 Tom Tromey
2023-10-03 17:56 ` [PATCH 1/3] Minor cleanup in linux_proc_attach_tgid_threads Tom Tromey
2023-10-04  1:29   ` Simon Marchi
2023-10-03 17:56 ` [PATCH 2/3] Use gdb_dir_up " Tom Tromey
2023-10-04  1:30   ` Simon Marchi
2023-10-03 17:56 ` [PATCH 3/3] Bail out of "attach" if a thread cannot be traced Tom Tromey
2023-10-04  1:29   ` Simon Marchi
2023-10-04 14:14     ` Tom Tromey
2023-10-04 17:38       ` Simon Marchi
2023-12-01 17:41 ` [PATCH 0/3] Fix "attach" infinite loop Tom Tromey
2023-12-04 14:25   ` Luis Machado
2023-12-05 19:27     ` Tom Tromey
2023-12-15 19:33       ` Tom Tromey
2023-12-18  9:50         ` Luis Machado
2023-12-18 11:33           ` Luis Machado
2023-12-18 14:30             ` Tom Tromey
2023-12-18 15:10               ` Luis Machado [this message]
2024-01-02 19:14                 ` 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=784a29ba-62ff-4518-9eca-ec20710a7581@arm.com \
    --to=luis.machado@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@adacore.com \
    /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).