Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 0/6] Fix PR gdb/19828 (attach -> internal error) and attach optimizations
Date: Thu, 19 May 2016 14:48:00 -0000	[thread overview]
Message-ID: <1463669290-30415-1-git-send-email-palves@redhat.com> (raw)

The goal of this series is fix PR gdb/19828.  In this series, I put
the fix for PR gdb/19828 last, but it actually fixes the bug on its
own.  However, that fix makes GDB add LWPs to the thread list sooner
and that ends up changing code paths in the attach sequence and
exposing inneficiencies that in turn result in
gdb.threads/attach-many-short-lived-threads.exp timing out almost
always on my machine...

So the first four patches of the series are about preemptively fixing
those time outs.

To make it easier to debug these inneficiencies, I applied patch #6
first, and then amplified the problem by hacking the
gdb.threads/attach-many-short-lived-threads.exp test program to spawn
thousands (2k-10k) of threads instead of dozens.

Then I simply ran the program in one terminal, and had gdb attach to
it from another terminal.

Without the other fixes, GDB would just never manage to finish
attaching to all LWPs.  With the fixes, GDB takes a few seconds to
fully attach.

So I suspect that this series ends up fixing the
gdb.threads/attach-many-short-lived-threads.exp racy timeouts seen on
some of the (probably slower) build slaves of our buildbot setup.

I have some other ideas to try as follow up, that I'll likely end up
exploring at some point, but I'll stop here for now.

(E.g., try group-stopping the process with SIGSTOP to have the kernel
freeze the whole thread group, though I think it may turn ugly and I
kind of dislike it as we should instead be moving in the direction of
PTRACE_SEIZE / PTRACE_INTERRUPT.)

Fedora 23 is carrying a simpler GDB fix for PR gdb/19828 that avoids
all these optimizations, but at the expense of leaving "attach&"
(background attach) still broken.  That might be safer to put in
7.11.1, but then again I dislike the idea of leaving attach& broken.
I'll find and post that patch for you all to see what I mean.

Pedro Alves (6):
  Linux native thread create/exit events support
  [Linux] Read vDSO range from /proc/PID/task/PID/maps instead of
    /proc/PID/maps
  [Linux] Avoid refetching core-of-thread if thread hasn't run
  [Linux] Optimize PID -> struct lwp_info lookup
  Make gdb/linux-nat.c consider a waitstatus pending on the infrun side
  Fix PR gdb/19828: gdb -p <process from a container>: internal error

 gdb/linux-nat.c                                   | 241 ++++++++++++++++++----
 gdb/linux-nat.h                                   |   4 +-
 gdb/linux-tdep.c                                  |  77 ++++---
 gdb/linux-thread-db.c                             |  14 +-
 gdb/testsuite/gdb.threads/clone-attach-detach.c   |  66 ++++++
 gdb/testsuite/gdb.threads/clone-attach-detach.exp |  98 +++++++++
 6 files changed, 428 insertions(+), 72 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/clone-attach-detach.c
 create mode 100644 gdb/testsuite/gdb.threads/clone-attach-detach.exp

-- 
2.5.5


             reply	other threads:[~2016-05-19 14:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 14:48 Pedro Alves [this message]
2016-05-19 14:48 ` [PATCH 1/6] Linux native thread create/exit events support Pedro Alves
2016-05-23 10:49   ` Yao Qi
2016-05-23 13:00     ` Pedro Alves
2016-05-19 14:48 ` [PATCH 2/6] [Linux] Read vDSO range from /proc/PID/task/PID/maps instead of /proc/PID/maps Pedro Alves
2016-05-23 11:08   ` Yao Qi
2016-05-19 14:48 ` [PATCH 3/6] [Linux] Avoid refetching core-of-thread if thread hasn't run Pedro Alves
2016-05-23 12:45   ` Yao Qi
2016-05-19 14:56 ` [PATCH 5/6] Make gdb/linux-nat.c consider a waitstatus pending on the infrun side Pedro Alves
2016-05-19 14:57 ` [PATCH 4/6] [Linux] Optimize PID -> struct lwp_info lookup Pedro Alves
2016-05-23 13:12   ` Yao Qi
2016-05-23 18:10     ` [PATCH v2/htab " Pedro Alves
2016-05-24  9:33       ` Yao Qi
2016-05-24 13:47         ` Pedro Alves
2016-05-19 14:57 ` [PATCH 6/6] Fix PR gdb/19828: gdb -p <process from a container>: internal error Pedro Alves
2016-05-23 10:14   ` Yao Qi
2016-05-25 17:43   ` [pushed/7.11.1] " Pedro Alves
2016-05-19 15:11 ` [PATCH 0/6] Fix PR gdb/19828 (attach -> internal error) and attach optimizations Pedro Alves
2016-05-24 13:57 ` Pedro Alves

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=1463669290-30415-1-git-send-email-palves@redhat.com \
    --to=palves@redhat.com \
    --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