public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/31832] [gdb] FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 3: attach (timeout)
Date: Wed, 12 Jun 2024 09:53:13 +0000	[thread overview]
Message-ID: <bug-31832-4717-deEcZfmexi@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-31832-4717@http.sourceware.org/bugzilla/>

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15582
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15582&action=edit
gdb.log (with statistics-gathering patch)

I applied the following statistics-gathering patch:
...
diff --git a/gdb/nat/linux-procfs.c b/gdb/nat/linux-procfs.c
index 5efc86cca1f..f6847257b85 100644
--- a/gdb/nat/linux-procfs.c
+++ b/gdb/nat/linux-procfs.c
@@ -22,6 +22,7 @@
 #include <sys/stat.h>
 #include <unordered_set>
 #include <utility>
+#include "gdbsupport/scope-exit.h"

 /* Return the TGID of LWPID from /proc/pid/status.  Returns -1 if not
    found.  */
@@ -377,17 +378,42 @@ linux_proc_attach_tgid_threads (pid_t pid,
      threads, new threads may be spawned.  Cycle through the list of
      threads until we have done two iterations without finding new
      threads.  */
+
+  unsigned long long total_iterations = 0;
+  unsigned long long dir_entries = 0;
+  unsigned long long no_lwp = 0;
+  unsigned long long lookup = 0;
+  unsigned long long skipped = 0;
+  unsigned long long insert = 0;
+  unsigned long long attach = 0;
+  unsigned long long start_over = 0;
+  SCOPE_EXIT
+    {
+      printf ("total_iterations: %llu\n", total_iterations);
+      printf ("dir_entries: %llu\n", dir_entries);
+      printf ("no_lwp: %llu\n", no_lwp);
+      printf ("lookup: %llu\n", lookup);
+      printf ("skipped: %llu\n", skipped);
+      printf ("insert: %llu\n", insert);
+      printf ("attach: %llu\n", attach);
+      printf ("start_over: %llu\n", start_over);
+    };
+
   for (iterations = 0; iterations < 2; iterations++)
     {
+      total_iterations++;
       struct dirent *dp;

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

          /* Fetch one lwp.  */
          lwp = strtoul (dp->d_name, NULL, 10);
+         if (lwp == 0)
+           no_lwp++;
          if (lwp != 0)
            {
              ptid_t ptid = ptid_t (pid, lwp);
@@ -399,12 +425,18 @@ linux_proc_attach_tgid_threads (pid_t pid,
                  std::pair<unsigned long, ULONGEST> key (lwp, *starttime);

                  /* If we already visited this LWP, skip it this time.  */
+                 lookup++;
                  if (visited_lwps.find (key) != visited_lwps.cend ())
-                   continue;
+                   {
+                     skipped++;
+                     continue;
+                   }

+                 insert++;
                  visited_lwps.insert (key);
                }

+             attach++;
              if (attach_lwp (ptid))
                new_threads_found = 1;
            }
@@ -414,6 +446,7 @@ linux_proc_attach_tgid_threads (pid_t pid,
        {
          /* Start over.  */
          iterations = -1;
+         start_over++;
        }

       rewinddir (dir.get ());
...
and ran the test-case.

The first iteration gives us:
...
(gdb) builtin_spawn
/home/vries/gdb/build/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads^M
attach 1301317^M
Attaching to program:
/home/vries/gdb/build/gdb/testsuite/outputs/gdb.threads/attach-many-short-lived-threads/attach-many-short-lived-threads,
process 1301317^M
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach (timeout)
total_iterations: 2092^M
dir_entries: 594518^M
no_lwp: 4412^M
lookup: 119037^M
skipped: 118355^M
insert: 682^M
attach: 471751^M
start_over: 2091^M
Cannot attach to lwp 2340832: Operation not permitted (1)^M
...

I'm not sure what this means, but I do notice the big difference between
dir_entries and lookup.  So only 20% of the time we find the starttime and can
use the cache.

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

  parent reply	other threads:[~2024-06-12  9:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-01  7:17 [Bug gdb/31832] New: " vries at gcc dot gnu.org
2024-06-01  7:23 ` [Bug gdb/31832] " vries at gcc dot gnu.org
2024-06-01  8:10 ` vries at gcc dot gnu.org
2024-06-02 12:36 ` bernd.edlinger at hotmail dot de
2024-06-03 16:58 ` vries at gcc dot gnu.org
2024-06-07  0:13 ` thiago.bauermann at linaro dot org
2024-06-12  9:53 ` vries at gcc dot gnu.org [this message]
2024-06-21  1:21 ` thiago.bauermann at linaro dot org
2024-06-21 10:18 ` vries at gcc dot gnu.org

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=bug-31832-4717-deEcZfmexi@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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).