From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26035 invoked by alias); 27 Dec 2016 16:43:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26021 invoked by uid 89); 27 Dec 2016 16:43:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.3.2 spammy=cure, birth, suspend, suspending X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Dec 2016 16:43:34 +0000 Received: by mail-wm0-f68.google.com with SMTP id u144so57952850wmu.0 for ; Tue, 27 Dec 2016 08:43:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :reply-to:references:mime-version:content-disposition:in-reply-to :user-agent; bh=3PCHcJ7lrwasgAiKLy4gw1bIENm3bFSJ6cWEcJ1dyqM=; b=QQTrfSBJnDTDqX7JCmw3IffKyBg5dNj0XXU6v3CDZI5hI5gHONIpup+CODgNyP/zOu kpGjq/Ud5Cl+cTJMrdepE//yRHP2X+hvWIafeBRsJhiX+ZUK3ngxt0LXV2u6LS+dwiY2 RqGwq+OY8TyTJMNqaEa4PkfHxl+k4ZkOmbi7VArgnSmTH4BZra/AmkzAY9F0/hleES4V wk/m5xvKdXnCpIjpsN+cRWxeM0L8rQ2eBfBqRTkP5b93Jol/0+PyD0VKYljuquKc6bSQ kv4NzFV4ssoYxh8b4x5syElset2OmVnhFExeRA5EfJfwLNc10fCjj2zvYJRFlHB1bevO Jctw== X-Gm-Message-State: AIkVDXKquts3cckJlPC929enDvXJMaJ4cCFAG3SFeJbAuisWFHniBbJvVFoOvwX2H6FnTQ== X-Received: by 10.28.166.20 with SMTP id p20mr30850229wme.87.1482857011718; Tue, 27 Dec 2016 08:43:31 -0800 (PST) Received: from localhost (BSN-143-156-237.dynamic.siol.net. [89.143.156.237]) by smtp.gmail.com with ESMTPSA id bf2sm59901087wjc.48.2016.12.27.08.43.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 08:43:30 -0800 (PST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 3a9953d7; Tue, 27 Dec 2016 17:43:29 +0100 (CET) Date: Tue, 27 Dec 2016 16:43:00 -0000 From: Vasil Dimov To: Luis Machado Cc: John Baldwin , gdb-patches@sourceware.org Subject: Re: [PATCH] PR threads/20743: Don't attempt to suspend or resume exited threads. Message-ID: <20161227164329.GA43600@nitro> Reply-To: vd@FreeBSD.org References: <20161223212842.42715-1-jhb@FreeBSD.org> <74b6668b-e98e-6034-99bd-fee9834fe9d4@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <74b6668b-e98e-6034-99bd-fee9834fe9d4@codesourcery.com> User-Agent: Mutt X-SW-Source: 2016-12/txt/msg00428.txt.bz2 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4173 On Fri, Dec 23, 2016 at 15:43:19 -0600, Luis Machado wrote: > On 12/23/2016 03:28 PM, John Baldwin wrote: > > When resuming a native FreeBSD process, ignore exited threads when > > suspending/resuming individual threads prior to continuing the process. > > > > gdb/ChangeLog: > > > > PR threads/20743 > > * fbsd-nat.c (resume_one_thread_cb): Ignore exited threads. > > (resume_all_threads_cb): Likewise. > > (fbsd_resume): Assert resuming thread has not exited. > > --- > > gdb/ChangeLog | 7 +++++++ > > gdb/fbsd-nat.c | 7 +++++++ > > 2 files changed, 14 insertions(+) > > > > diff --git a/gdb/ChangeLog b/gdb/ChangeLog > > index db6e913..4fb3732 100644 > > --- a/gdb/ChangeLog > > +++ b/gdb/ChangeLog > > @@ -1,3 +1,10 @@ > > +2016-12-23 John Baldwin > > + > > + PR threads/20743 > > + * fbsd-nat.c (resume_one_thread_cb): Ignore exited threads. > > + (resume_all_threads_cb): Likewise. > > + (fbsd_resume): Assert resuming thread has not exited. > > + > > 2016-12-22 Doug Evans > > > > * infrun.c (set_step_over_info): Add comment. > > diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c > > index ade62f1..7cd08c6 100644 > > --- a/gdb/fbsd-nat.c > > +++ b/gdb/fbsd-nat.c > > @@ -662,6 +662,9 @@ resume_one_thread_cb (struct thread_info *tp, void = *data) > > if (ptid_get_pid (tp->ptid) !=3D ptid_get_pid (*ptid)) > > return 0; > > > > + if (is_exited (tp->ptid)) > > + return 0; > > +=09=09 > > if (ptid_get_lwp (tp->ptid) =3D=3D ptid_get_lwp (*ptid)) > > request =3D PT_RESUME; > > else > > @@ -680,6 +683,9 @@ resume_all_threads_cb (struct thread_info *tp, void= *data) > > if (!ptid_match (tp->ptid, *filter)) > > return 0; > > > > + if (is_exited (tp->ptid)) > > + return 0; > > +=09=09 > > if (ptrace (PT_RESUME, ptid_get_lwp (tp->ptid), NULL, 0) =3D=3D -1) > > perror_with_name (("ptrace")); > > return 0; > > @@ -711,6 +717,7 @@ fbsd_resume (struct target_ops *ops, > > if (ptid_lwp_p (ptid)) > > { > > /* If ptid is a specific LWP, suspend all other LWPs in the proc= ess. */ > > + gdb_assert (!is_exited (ptid)); >=20 > If we're asserting on this (since supposedly it shouldn't happen), do we= =20 > need to check for is_exited on the two functions above? >=20 > Also, is there a reason why we're not detecting a thread that has=20 > exited? Aren't all threads stopped at this point (for all-stop mode at=20 > least)? [...] Hello, I just nailed this down after it has been annoying me for some time, fixed it with a similar patch as the one submitted by John, and came here to report it. The reason that we are "not detecting" an exited thread (at least in the scenario I got is), gdb/thread.c: --- cut --- static void delete_thread_1 (ptid_t ptid, int silent) { ... /* If this is the current thread, or there's code out there that relies on it existing (refcount > 0) we can't delete yet. Mark it as exited, and notify it. */ if (tp->refcount > 0 || ptid_equal (tp->ptid, inferior_ptid)) { ... /* Will be really deleted some other time. */ printf_unfiltered ("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Will be really = deleted some other time %u\n", ptid); return; } ... if (tpprev) tpprev->next =3D tp->next; else thread_list =3D tp->next; --- cut --- In my scenario tp->refcount is 0, but "ptid_equal (tp->ptid, inferior_ptid)" is true, so the thread's entry is not removed from the global "threads_list". The gdb output (with "set debug fbsd-lwp" enabled): --- cut --- FLWP: adding thread for LWP 102009 [New LWP 102009 of process 40304] FLWP: fbsd_resume for ptid (-1, 0, 0) FLWP: fbsd_resume for ptid (40304, 102009, 0) FLWP: fbsd_resume for ptid (-1, 0, 0) FLWP: fbsd_resume for ptid (40304, 102009, 0) FLWP: fbsd_resume for ptid (-1, 0, 0) FLWP: deleting thread for LWP 102009 [LWP 102009 of process 40304 exited] ... ptrace: No such process. --- cut --- Hope this helps. --=20 Vasil Dimov gro.DSBeerF@dv % There is no cure for birth and death other than to enjoy the interval. -- George Santayana --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSx1QTGJswNIJUlFLgXDpI/9sGkIAUCWGKaJwAKCRAXDpI/9sGk IHw4AKDOWTH+gOVE0z2o7pz8yp1G+AEFLgCgzGYoGY+SQu/tu0l791edPuV9tzA= =E2i7 -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--