From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit Date: Tue, 09 Aug 2022 14:43:04 +0300 Message-ID: <83czd9ve0n.fsf@gnu.org> References: <83pmj9qjgk.fsf@gnu.org> <8735e70xwl.fsf@gnus.org> <831qtrvtg5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56002@debbugs.gnu.org To: Tom Gillespie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 09 13:44:27 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLNes-0008iH-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Aug 2022 13:44:26 +0200 Original-Received: from localhost ([::1]:53982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLNer-0000LJ-0j for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Aug 2022 07:44:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLNeb-0000KN-3l for bug-gnu-emacs@gnu.org; Tue, 09 Aug 2022 07:44:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53024) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLNeU-0006hc-I4 for bug-gnu-emacs@gnu.org; Tue, 09 Aug 2022 07:44:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oLNeU-0002Ea-D6 for bug-gnu-emacs@gnu.org; Tue, 09 Aug 2022 07:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Aug 2022 11:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56002 X-GNU-PR-Package: emacs Original-Received: via spool by 56002-submit@debbugs.gnu.org id=B56002.16600454048531 (code B ref 56002); Tue, 09 Aug 2022 11:44:02 +0000 Original-Received: (at 56002) by debbugs.gnu.org; 9 Aug 2022 11:43:24 +0000 Original-Received: from localhost ([127.0.0.1]:42771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLNds-0002DX-23 for submit@debbugs.gnu.org; Tue, 09 Aug 2022 07:43:24 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLNdp-0002DJ-K9 for 56002@debbugs.gnu.org; Tue, 09 Aug 2022 07:43:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37742) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLNdk-0006ez-6H; Tue, 09 Aug 2022 07:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LSjtc+Tmt0pm2nG5npy/lZWQ0wUPY9ICUSq0N5FVuTU=; b=GPkSdLiEeRZC IQ0gZyIttYuta07U5BBIR4NuSElPhUXftrwMhnbUq2Ep+Gj3hADEkARcAkZG4SrK0Lgw5YG57WL/Y P3YKG68CLDwLOG2ti1N0C2iA0BZy8QhaNppWz72AsFYenq4VgWn3EwGxc+1SLRLJP4shNPAdyWJ0F OR8wenLYrhuuOxHx5ERnxJNeDJDFxnqzUgGSba8jdWYDLOvSrofw456OjggqZBsihmLjul3IVrDmw jJUmfu0yK5ZI1xJt3Mc/pk13II1t41R6rgyf+krInO0QOhQjn5Pj7acgPhWlQNKo7f4bkIMFq1R/+ TLg5qyqCWXTeJOFWU9Xamg==; Original-Received: from [87.69.77.57] (port=3371 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLNdj-0008SM-Ja; Tue, 09 Aug 2022 07:43:15 -0400 In-Reply-To: (message from Tom Gillespie on Mon, 8 Aug 2022 11:54:09 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239149 Archived-At: > From: Tom Gillespie > Date: Mon, 8 Aug 2022 11:54:09 -0700 > Cc: Lars Ingebrigtsen , 56002@debbugs.gnu.org > > > TBH, I don't understand the rationale well enough. What does it mean > > we "leak stderr process"? isn't the stderr process recycled if > > make-process fails? > > When the stderrproc is created internally there is no way that it can be > reused because nothing else has a reference to it. The changes here only > deal with cases where a stderrproc is not provided by the caller. This is a misunderstanding: I meant "recycled" as in "garbage-collected". GC in Emacs is supposed to prevent leaks of memory and resources. You seem to be saying that this somehow doesn't work in this case. Can you explain why it doesn't work, and which resources specifically appear to be leaking? > > Is it just a matter of some simple change in the > > control flow, to make sure we always go through the cleanup code > > before we return? > > There is no way easy way to modify the control flow because there are > so many possible points where process creation can fail unexpectedly > that must be handled if the stderrproc is created too early. But we have code that errors out in the middle of processing all over the place, and that is safe in Emacs, because any unused Lisp objects will be GC'ed soon. Why is this case special? > It is very hard to determine exactly which statements inside of make > process can produce unexpected exits, I have encountered at least > two, but I'm sure there are others. Thus the safest thing to do was to > move creation of stderrproc after all the points where process creation > can potentially fail (e.g. failures during vfork). > > > In general, I'd prefer not to change timing of what we do in > > make-process unless it's really unavoidable. There's a lot of > > system-dependent stuff there, and who knows what will that cause on > > some platform? > > I'm fairly certain that it is impossible for there to be any interaction between > the primary process and the stderr proc at any point in time prior to where > I moved the creation of the stderrproc because the first reference to > p->stderrproc after it is created is in create_process. I meant the potential interactions that are not explicitly visible by reading the code, but instead stem from system-dependent stuff that is related to how subprocesses are created on different systems. So I'd still be happier if we could deal with the problem without moving chunks of code around. Thanks.