From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VnyqNDQREWKkPQAAWB0awg (envelope-from ) for ; Sat, 19 Feb 2022 10:48:04 -0500 Received: by simark.ca (Postfix, from userid 112) id BD4F21F3C9; Sat, 19 Feb 2022 10:48:04 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2F4391EDF0 for ; Sat, 19 Feb 2022 10:48:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C301F3858D1E for ; Sat, 19 Feb 2022 15:48:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C301F3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1645285683; bh=/23Ggxio7J2LjitWRhScTIYww171mIdq3tW3/wjD7I0=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tQ/Se/X4EClDCevQdezbflWG+q26o58szCiyhjH6MeYFGZqAStrJkSPYLwKVqgKvd 9VNU0WKagpMxcIniX2XgSJpZKguHSBtphLudEilRkzPb0e2TBB/PcmmKicNLEuRemI vI5hkrjapqZwYfOwU8H9D8wcGYpvxRuxZS3HFXwg= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 47A783858D1E for ; Sat, 19 Feb 2022 15:47:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47A783858D1E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 21JFlTZL003166 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 19 Feb 2022 10:47:33 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 21JFlTZL003166 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6DE391EDF0; Sat, 19 Feb 2022 10:47:28 -0500 (EST) Message-ID: Date: Sat, 19 Feb 2022 10:47:28 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [RFC][PATCH v2 1/2][PR gdb/24069] [delete] Not-so-harmless spurious call to `wait4` Content-Language: en-US To: Philippe Blain , gdb-patches@sourceware.org References: <20210408191449.27434-1-dominique.quatravaux@epfl.ch> <20220216141540.96514-1-levraiphilippeblain@gmail.com> <20220216141540.96514-2-levraiphilippeblain@gmail.com> In-Reply-To: <20220216141540.96514-2-levraiphilippeblain@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sat, 19 Feb 2022 15:47:29 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Louis-He <1726110778@qq.com>, Dominique Quatravaux , Sam Warner Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-02-16 09:15, Philippe Blain wrote: > From: Dominique Quatravaux > > As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this > code will typically wait4() a second time on the same process that was > already wait4()'d a few lines above. While this used to be > harmless/idempotent (when we assumed that the process already exited), > this now causes a deadlock in the WIFSTOPPED case. > > The early (~2019) history of bug #24069 cautiously suggests to use > WNOHANG instead of outright deleting the call. However, tests on the > current version of Darwin (Big Sur) demonstrate that gdb runs just > fine without a redundant call to wait4(), as would be expected. > Notwithstanding the debatable value of conserving bug compatibility > with an OS release that is more than a decade old, there is scant > evidence of what that double-wait4() was supposed to achieve in the > first place - A cursory investigation with `git blame` pinpoints > commits bb00b29d7802 and a80b95ba67e2 from the 2008-2009 era, but > fails to answer the “why” question conclusively. Given that this additional wait does not seem logical at all and empirical evidence shows that it's not right, I'm fine with merging this one directly. Do you have push access, or would you like me to do it on your behalf? Simon