From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40742 invoked by alias); 7 Jul 2015 18:47:10 -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 40728 invoked by uid 89); 7 Jul 2015 18:47:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Jul 2015 18:47:08 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8745E8E717; Tue, 7 Jul 2015 18:47:07 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t67Il5di011572; Tue, 7 Jul 2015 14:47:06 -0400 Message-ID: <559C1EA9.5090400@redhat.com> Date: Tue, 07 Jul 2015 18:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Simon Marchi , Joel Brobecker CC: gdb-patches Subject: Re: Should this be on the blocker list for the 7.10 release? References: <559AE482.1010109@ericsson.com> <20150707132459.GA16734@adacore.com> <559BFBBD.4000303@redhat.com> <559C14B6.5020800@redhat.com> <559C1BFB.7070308@ericsson.com> In-Reply-To: <559C1BFB.7070308@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00188.txt.bz2 On 07/07/2015 07:35 PM, Simon Marchi wrote: >> OK, the issue is that the new clone thread is found while inside >> the linux_stop_and_wait_all_lwps call in this new bit of >> code in linux-thread-db.c: >> >> linux_stop_and_wait_all_lwps (); >> >> ALL_LWPS (lp) >> if (ptid_get_pid (lp->ptid) == pid) >> thread_from_lwp (lp->ptid); >> >> linux_unstop_all_lwps (); >> >> We reach linux_handle_extended_wait with the "stopping" >> parameter set to 1, and because of that we don't mark the >> new lwp as resumed. As consequence, the subsequent >> resume_stopped_resumed_lwps (called first from that >> linux_unstop_all_lwps) never resumes the new LWP... >> >> There's lots of cruft in linux_handle_extended_wait that no >> longer makes sense. This seems to fix your github test >> for me, and causes no testsuite regressions. > > It seems to fix most of it. The only odd thing left that I > noticed is that it leaves some of the inferiors there. When I > type "info inferiors" after running the program, I see one or > two of them left. I believe there should only be inferior #1 > left. Hmm, indeed: (gdb) info inferiors Num Description Executable 4 process 8393 /home/pedro/bugs/src/test 2 process 8388 /home/pedro/bugs/src/test * 1 /home/pedro/bugs/src/test (gdb) info threads Calling prune_inferiors() at this point (from a top gdb) does not remove them, because they still have inf->pid != 0. Sounds like we miss mourning inferiors 2 and 4 somehow? Thanks, Pedro Alves