[Bug testsuite/31312] attach-many-short-lived-threads gives inconsistent results

["thiago.bauermann at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31312

--- Comment #17 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Created attachment 15405
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15405&action=edit
Shameless workaround.

I don't have any certainty yet, but I have a few suspicions, and the attached
workaround...

I believe (still have to confirm this) that when GDB is stuck using 100% of the
CPU, it's here 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 < 20; 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 ());
    }

In this case, the attach_lwp function pointer being called is
attach_proc_task_lwp_callback (), and the relevant part of it is:

  if (ptrace (PTRACE_ATTACH, lwpid, 0, 0) < 0)
    {
      int err = errno;

      /* Be quiet if we simply raced with the thread exiting.
         EPERM is returned if the thread's task still exists, and
         is marked as exited or zombie, as well as other
         conditions, so in that case, confirm the status in
         /proc/PID/status.  */
      if (err == ESRCH
          || (err == EPERM && linux_proc_pid_is_gone (lwpid)))
        {
          linux_nat_debug_printf
            ("Cannot attach to lwp %d: thread is gone (%d: %s)",
             lwpid, err, safe_strerror (err));
        }

So this is what I think is going on (again, I still need to confirm):

1. linux_proc_attach_tgid_threads () loops through tasks in /proc/PID/task,
calling attach_proc_task_lwp_callback () on each of them.

2. ptrace (PTRACE_ATTACH) returns -1 with errno = EPERM, causing
linux_proc_pid_is_gone () to get called.

3. linux_proc_pid_is_gone () opens /proc/LWP/status and sees that the thread
state is zombie or dead.

4. attach_proc_task_lwp_callback () returns 1, indicating that a new thread was
found.

5. linux_proc_attach_tgid_threads () sets new_threads_found = 1 and loops
again, finding the same thread in /proc/PID/task again because for some reason
the kernel isn't removing its proc entry any time soon.

6. GOTO 1.

So my suspicion is that what is confusing GDB is that the kernel (probably!
have to confirm...) is keeping the /proc entry for zombie and dead threads
around indefinitely.

Anyway, regarding the workaround: it's not very satisfying because increasing
the number of iterations in linux_proc_attach_tgid_threads () goes back to the
heuristic that Pedro's commit 8784d56326e7 ("Linux: on attach, attach to lwps
listed under /proc/$pid/task/") removed. Not increasing it makes GDB leave some
threads unattached and the inferior dies with a SIGTRAP due to the breakpoint
(which is exactly the scenario the testcase is designed to catch). Using 20
still triggers the problem relatively easily for me, after 100 tries of running
the testcase in a loop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.