From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125309 invoked by alias); 7 Jul 2015 19:04:54 -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 125299 invoked by uid 89); 7 Jul 2015 19:04:53 -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 19:04:53 +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 D254EAB9; Tue, 7 Jul 2015 19:04:51 +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 t67J4oo0020402; Tue, 7 Jul 2015 15:04:50 -0400 Message-ID: <559C22D1.7020501@redhat.com> Date: Tue, 07 Jul 2015 19:04: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> <559C1EA9.5090400@redhat.com> In-Reply-To: <559C1EA9.5090400@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00189.txt.bz2 On 07/07/2015 07:47 PM, Pedro Alves wrote: > 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? I think I got it. Enabling logs (master + previous patch) I see: ... WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped) WL: Handling extended status 0x03057f LHEW: Got clone event from LWP 9513, new child is LWP 9579 [New Thread 0x7ffff37b8700 (LWP 9579)] WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited) WL: Thread 0x7ffff7fc2740 (LWP 9508) exited. ^^^^^^^^ [Thread 0x7ffff7fc2740 (LWP 9508) exited] WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited) WL: Thread 0x7ffff7fc2740 (LWP 9499) exited. [Thread 0x7ffff7fc2740 (LWP 9499) exited] RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0 ... (gdb) info inferiors Num Description Executable 5 process 9508 /home/pedro/bugs/src/test ^^^^ 4 process 9503 /home/pedro/bugs/src/test 3 process 9500 /home/pedro/bugs/src/test 2 process 9499 /home/pedro/bugs/src/test * 1 /home/pedro/bugs/src/test (gdb) ... Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line. That's this in wait_lwp: /* Check if the thread has exited. */ if (WIFEXITED (status) || WIFSIGNALED (status)) { thread_dead = 1; if (debug_linux_nat) fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n", target_pid_to_str (lp->ptid)); } } This code doesn't understand that an WIFEXITED status of the last lwp of the process should be reported as process exit. Haven't tried to fix it yet. I haven't tried 7.9, but I'd think it possible to trigger this issue in all-stop there, because all it takes is a whole process exiting while gdb is iterating over lwps, stopping them. Thanks, Pedro Alves