From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3369 invoked by alias); 13 Aug 2018 13:38:17 -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 3355 invoked by uid 89); 13 Aug 2018 13:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Aug 2018 13:38:14 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2540A7CBBA; Mon, 13 Aug 2018 13:38:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 70EED20389E0; Mon, 13 Aug 2018 13:38:12 +0000 (UTC) Subject: Re: [PATCH] gdb: Fix instability in thread groups test To: Andrew Burgess References: <20180810095750.13017-1-andrew.burgess@embecosm.com> <7da382e5-bd5e-25c2-b3f8-f38e692f35a1@redhat.com> <20180813114137.GX3155@embecosm.com> <2e47657d-b81b-497d-58bf-0463980dec24@redhat.com> <20180813130125.GY3155@embecosm.com> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <7ab394a0-f796-4ff3-65e2-c7db9d7063e7@redhat.com> Date: Mon, 13 Aug 2018 13:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180813130125.GY3155@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00331.txt.bz2 On 08/13/2018 02:01 PM, Andrew Burgess wrote: > * Pedro Alves [2018-08-13 13:03:47 +0100]: >> I wonder whether we can prevent PID reuse by keeping a descriptor >> for /proc/PID/ open while we open the other files. Probably not. > > That was my first though, I tried: > > - chdir /proc/PID > - opendir for /proc/PID > > - Kill /proc/PID > > - Read from the opendir handle, find nothing there. > > Which didn't really surprise me, but was worth a try... Does it return "nothing else" even if you don't kill the process? Or does returning nothing indicate the process is gone already? Regardless, I don't think that proves keeping the opendir dir handle open (or some other file under /proc/PID) does not prevent the kernel from reusing the PID until the handle is closed, even though I do suspect it does not. But thinking a bit more, maybe it's useless to try to detect PID reuse, because the process we're collecting info for can just as well exec, which makes the info we had collected so far become invalid in pretty much the same way... >>> and the original patch to remove the unstable result applied? >>> Or maybe the test updated to either PASS or KFAIL? >> >> I'd prefer the KFAIL option. At the very least, a comment in >> the .exp file. > > I'll put something together... Maybe it's not worth the bother. After thinking about it some more, I'll be happy with a comment in the .exp file. Pedro Alves