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: Wed, 10 Aug 2022 21:06:33 +0300 Message-ID: <8335e4q8gm.fsf@gnu.org> References: <83pmj9qjgk.fsf@gnu.org> <8735e70xwl.fsf@gnus.org> <831qtrvtg5.fsf@gnu.org> <83czd9ve0n.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34025"; 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 Wed Aug 10 20:07:22 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 1oLq70-0008hl-8P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 20:07:22 +0200 Original-Received: from localhost ([::1]:39188 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLq6z-00032N-0s for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 14:07:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLq6h-00032B-6g for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 14:07:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60984) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLq6g-0001Wg-61 for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 14:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oLq6f-00038z-VT for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 14:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Aug 2022 18:07:01 +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.166015481412072 (code B ref 56002); Wed, 10 Aug 2022 18:07:01 +0000 Original-Received: (at 56002) by debbugs.gnu.org; 10 Aug 2022 18:06:54 +0000 Original-Received: from localhost ([127.0.0.1]:50733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLq6Y-00038d-58 for submit@debbugs.gnu.org; Wed, 10 Aug 2022 14:06:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLq6S-00038L-TX for 56002@debbugs.gnu.org; Wed, 10 Aug 2022 14:06:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38234) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLq6N-0001Va-GB; Wed, 10 Aug 2022 14:06:43 -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=BFVdETWQFbqceQuNnSdjhlUbZcOBmXnoMT8e3kEHhkk=; b=IoskJAYwLD4f oLIP8KEKHXE3NnUvm2ZVBI5uRzqDqnh+2xhZDaSMjS77b+deCnYaB6H6l2kbfBQjfKvNa/R/OFYRW qjwewBhUR6QhxQLU1AgbKtFqbiLMG+LIAjR8bzNNhuCGE9nZZPEm8rJgAlQNo6iTDxvjxAWTMv//k VUkNU3uKx7ULPdTaKP2SX+MI5FA/irhEecqDcJlZLla+C/J8AahqGXEVZt3oh7+HDclCqumhUv0Mv Ku4d+H7XIfZ401q+0q2xo8oZyJQmX7pj6Y+Zcf40e4QFFgYoTH4HNLUrL8eHzkGGFn2Sy5V3NoGdc ThJ1br/7+SOzWSshI5tuIQ==; Original-Received: from [87.69.77.57] (port=4005 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 1oLq6M-0007PZ-2N; Wed, 10 Aug 2022 14:06:43 -0400 In-Reply-To: (message from Tom Gillespie on Tue, 9 Aug 2022 11:59:19 -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:239314 Archived-At: > From: Tom Gillespie > Date: Tue, 9 Aug 2022 11:59:19 -0700 > Cc: larsi@gnus.org, 56002@debbugs.gnu.org > > > 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? > > Ah. It doesn't work because in this failure mode stderrproc is never gced > because it is still running and attached to a buffer. This is because it is in > a bad state where it cannot exit because it cannot receive a signal from > the non-existent primary process. See the example below where you will > be prompted to kill stderr-buffer after sleeping and gc. Sorry, I don't understand: stderrproc in this case is not a real process, it's just a process object. So why does it need to receive a signal? To clean it up, make-process "just" needs to make sure this "process" is killed and its resources released before it returns unsuccessfully. Right? > > 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. > > My reading of make-process is that it is impossible for callers in > the elisp universe to see an internally created stderrproc until after > create-process returns so implicit interactions on the elisp side > never happen. That's not what I meant. I meant the hidden dependencies on the timing and the order of doing things. For example, you are talking about vfork all the time, so I presume you didn't analyze what happens in a build that uses posix_spawn instead (see emacs_spawn), or when we launch subprocesses on MS-Windows. They use different system calls in different orders, and I worry that we could introduce subtle bugs by rocking this delicate boat. > The alternative is to add code to clean up the stderrproc for any > possible failure during make-process after it has been created, > though I'm not sure that is actually possible. Maybe I'm misunderstand something here, but the usual way of doing that is to use record_unwind_protect immediately after creating the stderr process, with a suitable unwind function that would perform the necessary cleanup. This ensures that however we exit make-process, the cleanup is never missed, and we don't leak resources. Why cannot we do this here? What am I missing?