From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.bugs Subject: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit Date: Mon, 8 Aug 2022 11:54:09 -0700 Message-ID: References: <83pmj9qjgk.fsf@gnu.org> <8735e70xwl.fsf@gnus.org> <831qtrvtg5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4926"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 56002@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 08 20:55:19 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 1oL7uH-000149-QI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Aug 2022 20:55:17 +0200 Original-Received: from localhost ([::1]:51192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL7uG-0007ZG-8z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Aug 2022 14:55:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL7u3-0007Yx-5V for bug-gnu-emacs@gnu.org; Mon, 08 Aug 2022 14:55:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52245) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oL7u2-0003pH-B3 for bug-gnu-emacs@gnu.org; Mon, 08 Aug 2022 14:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oL7u2-0004k9-2l for bug-gnu-emacs@gnu.org; Mon, 08 Aug 2022 14:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tom Gillespie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Aug 2022 18:55: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.165998487018183 (code B ref 56002); Mon, 08 Aug 2022 18:55:02 +0000 Original-Received: (at 56002) by debbugs.gnu.org; 8 Aug 2022 18:54:30 +0000 Original-Received: from localhost ([127.0.0.1]:41994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oL7tW-0004jD-2V for submit@debbugs.gnu.org; Mon, 08 Aug 2022 14:54:30 -0400 Original-Received: from mail-pg1-f181.google.com ([209.85.215.181]:34408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oL7tS-0004iy-G7 for 56002@debbugs.gnu.org; Mon, 08 Aug 2022 14:54:29 -0400 Original-Received: by mail-pg1-f181.google.com with SMTP id 12so9378603pga.1 for <56002@debbugs.gnu.org>; Mon, 08 Aug 2022 11:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=YsBvHrrVS4e8EHzh8u89N0Zvi5n8j/VHNj9RP/AVLD0=; b=iXBBHqo492C4sr6CD91h/yRKpV59KrORRcnRuiLCD/jxNTsCaGMxL1Nx+cCDI9JXUz w9fnKSBnHyvSJKVmSz4mTXXpr7JW/nDog17bE0LNlOaV8gAUcT7BPZzwtq/YFQplwRe2 BdSqTnYp0/MkjuslCzLX7bbGAIj3+bVwRJSJcGdQHpxaqdaBD9u2xkr3kudym0uhBPDl DOGO6SuM02sqTvuApqIEXlH83sE5C0z5bSKyRcwUcMTcvvt7e8IXNopdQxUD/GL78/6T eXzFTWOK9QXlJQrlqsztOIFB2cL7mkUFVTaU0zM+T8PXo+bJcPblLVeD5btWDxsWAwOX fx6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=YsBvHrrVS4e8EHzh8u89N0Zvi5n8j/VHNj9RP/AVLD0=; b=6C0w2/5sJ6GAknd9FwwrvK4qzxc7c0wZ8oJgup4HPYSD0W8IOpnwsaAMywBasoABCU OXHmWeT0v9dN+dlj6KPwLKz4BNXk6RvWnv85yCEwbcadQ+/CZvhgA+W1eH9ows1weqYx 6SKyw5qULYyoA6VD08h1r7GraVauk3f7yoTmUHLmkLNMyxzqDQawrXt4TZDWopNHstFY QDqpXX+a8g5WakmcgELEM2A3jE43RNuEDI07b3ENxFy9Mn0A6r6sIhDttXAk+Tz46Ghi GJO357cVG4ssZnok2KB+YTpIGLACDQ0bLepTYfMWqFYZSL2FxjbUQO1xCqdHtr6diCBv ztQQ== X-Gm-Message-State: ACgBeo0QHhKOSwRFXqow6NesppyKBif9JpP4x64l5JLBiY1QaLSPRX64 6Xy3vw5ZWFyao0QSA90EMehZspPpq/SX/50/yQw= X-Google-Smtp-Source: AA6agR60Ou3IkvXBmqPrfrR9eB4UVigrMNmwGyFIKcTqr6nMUJDpL5CcnmZ9NUeUxeT5KaSKhxjHY4L2p/TRNIwGTA4= X-Received: by 2002:a62:3086:0:b0:52b:fd6c:a49d with SMTP id w128-20020a623086000000b0052bfd6ca49dmr19285464pfw.26.1659984860524; Mon, 08 Aug 2022 11:54:20 -0700 (PDT) In-Reply-To: <831qtrvtg5.fsf@gnu.org> 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:239128 Archived-At: > 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. > 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. 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.