From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18783 invoked by alias); 28 Dec 2016 17:37:48 -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 18771 invoked by uid 89); 28 Dec 2016 17:37:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=whereby, johns, Johns, suspend X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Dec 2016 17:37:45 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 4491D10A745; Wed, 28 Dec 2016 12:37:43 -0500 (EST) From: John Baldwin To: vd@freebsd.org Cc: Luis Machado , gdb-patches@sourceware.org Subject: Re: [PATCH] PR threads/20743: Don't attempt to suspend or resume exited threads. Date: Wed, 28 Dec 2016 17:37:00 -0000 Message-ID: <1700771.1OUYESxIQe@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20161228080707.GA4007@nitro> References: <20161223212842.42715-1-jhb@FreeBSD.org> <2893581.89CAWbS1EM@ralph.baldwin.cx> <20161228080707.GA4007@nitro> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00434.txt.bz2 On Wednesday, December 28, 2016 09:07:07 AM Vasil Dimov wrote: > On Tue, Dec 27, 2016 at 13:03:27 -0800, John Baldwin wrote: > [...] > > I have tried changing fbsd_wait() to return a TARGET_WAITKIND_SPURIOUS > > instead of explicitly continuing the process, but that doesn't help, and it > > means that the ptid being returned is still T1 in that case. > > > > I'm not sure if I should explicitly be calling delete_exited_threads() in > > fbsd_resume() before calling iterate_threads()? Alternatively, fbsd_resume() > > could use ALL_NONEXITED_THREADS() instead of iterate_threads() (it isn't > > clear to me which of these is preferred since both are in use). > > > > I added the assertion for my own sanity. I suspect gdb should never try to > > invoke target_resume() with a ptid of an exited thread, but if for some > > reason it did the effect on FreeBSD would be a hang since we would suspend > > all the other threads and when the process was continued via PT_CONTINUE it > > would have nothing to do and would never return from wait(). I'd rather have > > gdb fail an assertion in that case rather than hang. > [...] > > Hi, > > I am not sure if this is related, but since I get a hang I would rather > mention it: with the John's patch (including the assert) gdb does not > emit the "ptrace: No such process" error, but when I attempt to quit, > it hangs: No, this is a separate bug in the kernel whereby a process doesn't treat PT_KILL as a detach-like event but incorrectly expects to keep getting PT_CONTINUE events for a while until it finally exits. I'm working on writing up regression/unit tests for PT_KILL and then fixing the bug. -- John Baldwin