Created attachment 12718 [details]
gdb.log

Reproduced today on master, so it's not a fluke.

FTR: on openSUSE Leap 15.2 laptop.

It is not a bug but security issue. Due to ptrace protection, if you wanna attach another process without "parent-child relationship", it is illegal behavior.

There are two different way to solve this issue.
1. Execute under root level
2. Set "/proc/sys/kernel/yama/ptrace_scope" into 0.

(In reply to Chungyi Chi from comment #3)
> It is not a bug but security issue. Due to ptrace protection, if you wanna
> attach another process without "parent-child relationship", it is illegal
> behavior.
> 
> There are two different way to solve this issue.
> 1. Execute under root level
> 2. Set "/proc/sys/kernel/yama/ptrace_scope" into 0.

On my system, there's no yama:
...
$ cat /sys/kernel/security/lsm 
lockdown,capability,apparmor
$
...

Also, I don't understand how yama would cause the specific failure reported in this PR.  If yama were active, wouldn't things fail much earlier, and in much more tests?

I also encountered this issue with current master branch on 3 machines: two
x86_64-linux and one aarch64-linux. Carl Love also reported in bug #31312
that he encountered the issue on a powerpc64le-linux system. The aarch64
and powerpc64le machines had a patch to fix bug #31312 applied.

In all cases it's necessary to keep running
attach-many-short-lived-threads.exp in a loop to reproduce the problem. In
one of the x86_64-linux machines it takes anywhere from 30 to 500
iterations to hit the problem, while in the other it took between 120 and
900 iterations. The aarch64-linux machine took ~2500 iterations. In
powerpc64le-linux, the problem happened in 3 iterations out of 500.

I do have Yama present in those machines, but it is disabled in all of
them:

  $ sysctl kernel.yama.ptrace_scope
  kernel.yama.ptrace_scope = 0

I also agree with Tom that if Yama was the problem, it would affect the
testcase in a different way.

The issue arises from this loop in linux_proc_attach_tgid_threads ():

  /* Scan the task list for existing threads.  While we go through the
     threads, new threads may be spawned.  Cycle through the list of
     threads until we have done two iterations without finding new
     threads.  */
  for (iterations = 0; iterations < 2; iterations++)
    {
      struct dirent *dp;

      new_threads_found = 0;
      while ((dp = readdir (dir.get ())) != NULL)
	{
	  unsigned long lwp;

	  /* Fetch one lwp.  */
	  lwp = strtoul (dp->d_name, NULL, 10);
	  if (lwp != 0)
	    {
	      ptid_t ptid = ptid_t (pid, lwp);

	      if (attach_lwp (ptid))
		new_threads_found = 1;
	    }
	}

      if (new_threads_found)
	{
	  /* Start over.  */
	  iterations = -1;
	}

      rewinddir (dir.get ());
    }

What happens is that two iterations without seeing new threads in
linux_proc_attach_tgid_threads () isn't always enough for GDB to know that
it has attached to all inferior threads. So sometimes after this function
returns, an unattached inferior thread trips on the breakpoint instruction
that GDB put in the inferior.

I don't know if I would consider this a bug, but rather an issue that
arises from the way attach-many-short-lived-threads.c behaves: since it's
constantly creating new threads it's impossible for GDB to know when it has
attached to all of them so that it can finish looking for new threads to
attach.

The only way I can see to improve GDB's behaviour is to increase the number
of iterations of the loop that checks for new threads.

I suspected that the ability of the inferior to create new threads was
proportional to the number of CPUs present in the system so I was going to
make the number of iterations in linux_proc_attach_tgid_threads ()
proportional to the number of CPUS, but on the machines I have at hand, the
one where it takes longest to reproduce the problem has the most CPUs (160,
vs 8 CPUs on the other machines), so maybe we just have to find a magical
iteration number that works well for everybody who can reproduce the issue?