Received: (at 56002) by debbugs.gnu.org; 9 Aug 2022 18:59:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 09 14:59:39 2022
Received: from localhost ([127.0.0.1]:45033 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oLUS3-0003fR-6L
for submit <at> debbugs.gnu.org; Tue, 09 Aug 2022 14:59:39 -0400
Received: from mail-pg1-f174.google.com ([209.85.215.174]:43570)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <tgbugs@HIDDEN>) id 1oLUS1-0003fE-Bd
for 56002 <at> debbugs.gnu.org; Tue, 09 Aug 2022 14:59:38 -0400
Received: by mail-pg1-f174.google.com with SMTP id h132so12183602pgc.10
for <56002 <at> debbugs.gnu.org>; Tue, 09 Aug 2022 11:59:37 -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=VlBvticDxxAWa9+GXorAJKq3ymfvJ5VFlNrNOl2RHIg=;
b=eWe2fykxdkC/LsH9sLiN5Nd2BC61eHtzvwOq+cIn2wdmZ7Yo2lyt45s7rR4rfZw6s1
b7Yq4EtcO3BMySjBRBFMsgnpxdgkroOdk5k+mUe3S9EGbXG2zCMpVxpU/5xtOG8zdkYF
AI26cjJqYuuSJtQOI1MCKCVrVtlEzIC8QMpgY57EzJbBs7WlJlckmZJyj+S4Oy6b6OK1
qD0ANo2YzSPx6+eKlAczl/nVSHdAQQBJMNZfXprFNQeHXbg+dlz8KNensVNYwcARP/WG
znQe6+LY3Gn24dJ8OEAIR3pAt356i1ArkESvYv2OmuTvNm61cvH14VfxJbEnBOft7FMh
rLdQ==
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=VlBvticDxxAWa9+GXorAJKq3ymfvJ5VFlNrNOl2RHIg=;
b=H+n2kJhM9fKqMNM/Rus59MG6tLoT4VwgLAMkDgCkZ0fA8Uzlx/RY+7Yp1VK6zbYlae
hcts8hpiZrpUUY5qfAP91cqeidNP5Et+aXTw/HyA1+BCwZj+sb3fGVHQq6p0HwieU6FF
n4YtftKdxbOjAwZmxTGRmLwsA73TV/197lyH+qEr15pOksKHRD+pZOLhT5ihLbjXipkq
+z3W6IboVqXVMR0ao/Cj/NRW/T6iqqPICAXU8BLFyJQqlPnhV6WJ/HLPL9XQbB+7X2r0
4Vch0JyV2VzktNyckJCur+w6kRBftcjRXoSKrNG9+59Fsne5UIyixsDEC5KLFzKVX4Rc
NxhQ==
X-Gm-Message-State: ACgBeo29zsdFOJAESmrFpQVcCrXPfQBA2LtVleWQnuqKK1J7/QFTOKeo
2/K+oMEvT6RTCZgz0cbspI9RvZzHz24IijjoQZ4=
X-Google-Smtp-Source: AA6agR7Ebyj/MkQK7ALT0kXk8gafTBXAR6B5+59nGT7qNIhItzRm8Ywi7nOOz9FaCAPLzo+z2bFE8V+eRy46R6OAN8s=
X-Received: by 2002:a05:6a00:e85:b0:52b:5db8:f3df with SMTP id
bo5-20020a056a000e8500b0052b5db8f3dfmr24188429pfb.14.1660071571181; Tue, 09
Aug 2022 11:59:31 -0700 (PDT)
MIME-Version: 1.0
References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN>
<83pmj9qjgk.fsf@HIDDEN>
<CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN>
<CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN>
<CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN>
<8735e70xwl.fsf@HIDDEN> <831qtrvtg5.fsf@HIDDEN>
<CA+G3_POmUnEozARB4WhLsM5esYOyQPKAKwPD7XxyZLRVWAZPCg@HIDDEN>
<83czd9ve0n.fsf@HIDDEN>
In-Reply-To: <83czd9ve0n.fsf@HIDDEN>
From: Tom Gillespie <tgbugs@HIDDEN>
Date: Tue, 9 Aug 2022 11:59:19 -0700
Message-ID: <CA+G3_POSq2gxJO-M63DtkgmOkoZjsrY2jp6JA4G93+J37zjhxQ@HIDDEN>
Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr
process on early exit
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 56002
Cc: larsi@HIDDEN, 56002 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> 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.
#+begin_src bash
read -r -d '' example <<'EOF'
(progn
(setq stderr-buffer (generate-new-buffer " rc stderr"))
(condition-case nil
(make-process
:name "process that never actually starts"
:stderr stderr-buffer
:query-stderr t
:command '("i_fail_before_there_can_be_a_return_code"))
(error t))
(message "%S" (get-buffer-process stderr-buffer))
(sleep-for 1)
(garbage-collect)
(message "%S" (get-buffer-process stderr-buffer))
(kill-buffer stderr-buffer))
EOF
emacs -Q -batch -eval "${example}"
#+end_src
> 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?
There are a few reasons why this is special.
0. An internally created stderrproc will never be gced if the parent process
fails to be created for the reasons listed below.
1. A vfork failure or being passed a command that does not exist causes
a make-process to fail in a way that a) leaves stderrproc attached to the
stderr buffer and b) leaves stderrproc in a bad state where it cannot receive
a signal from the primary process to exit because the primary process
never makes it into existence
2. Once created, stderrproc is attached to a buffer and that buffer is
not guaranteed to be gced if the caller e.g. passes in a buffer they
want to persist.
3. Elisp code can and does interact with stderr buffers that have
this zombie stderrproc as their buffer 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.
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.
On the C side there are already implicit interactions that exist
and can fail because the original code as written did not account
for them, such as failures during vfork or a command that does
not exist, and this patch prevents those.
To the best of my knowledge the point to which I moved the call
to create stderrproc minimize all possible implicit interactions.
It is a pipe process that nothing else cares about or depends on
until create_process gets stderrproc's stdout file descriptor and
passes it to emacs_spawn as fd_error.
> So I'd still be happier if we could deal with the problem without
> moving chunks of code around.
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.
It is vastly easier, requires much less code, and leaves no doubt
as to whether we missed a call that could fail, to simply move
the creation of stderrproc to a point after all those potential
failure conditions but before it is ever accessed or needed by
other parts of the system.
To quote my internal notes while debugging the issue:
>> there is literally no way to automatically clean up the stderr buffer
>> no matter what you do if there is an error during process creation
Of course the caller could add a call to get-buffer-process and kill the
thing, but there shouldn't even be a process attached to the stderr buffer
because the call to make-process failed.
Without this patch make-process is fundamentally broken and every
caller that wants to clean up the stderr buffer on error but also prompt
on exit would have to know about this issue and call get-buffer-process
on the stderr buffer and then kill that process manually because it is in
a bad state and will not terminate by itself. All this assuming that they
could even figure out what was happening and find this bug report.
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 9 Aug 2022 11:43:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 09 07:43:24 2022 Received: from localhost ([127.0.0.1]:42771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oLNds-0002DX-23 for submit <at> debbugs.gnu.org; Tue, 09 Aug 2022 07:43:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1oLNdp-0002DJ-K9 for 56002 <at> debbugs.gnu.org; Tue, 09 Aug 2022 07:43:22 -0400 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 <eliz@HIDDEN>) 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==; 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 <eliz@HIDDEN>) id 1oLNdj-0008SM-Ja; Tue, 09 Aug 2022 07:43:15 -0400 Date: Tue, 09 Aug 2022 14:43:04 +0300 Message-Id: <83czd9ve0n.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Tom Gillespie <tgbugs@HIDDEN> In-Reply-To: <CA+G3_POmUnEozARB4WhLsM5esYOyQPKAKwPD7XxyZLRVWAZPCg@HIDDEN> (message from Tom Gillespie on Mon, 8 Aug 2022 11:54:09 -0700) Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> <8735e70xwl.fsf@HIDDEN> <831qtrvtg5.fsf@HIDDEN> <CA+G3_POmUnEozARB4WhLsM5esYOyQPKAKwPD7XxyZLRVWAZPCg@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56002 Cc: larsi@HIDDEN, 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Tom Gillespie <tgbugs@HIDDEN> > Date: Mon, 8 Aug 2022 11:54:09 -0700 > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 56002 <at> 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.
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 8 Aug 2022 18:54:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 08 14:54:30 2022 Received: from localhost ([127.0.0.1]:41994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oL7tW-0004jD-2V for submit <at> debbugs.gnu.org; Mon, 08 Aug 2022 14:54:30 -0400 Received: from mail-pg1-f181.google.com ([209.85.215.181]:34408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tgbugs@HIDDEN>) id 1oL7tS-0004iy-G7 for 56002 <at> debbugs.gnu.org; Mon, 08 Aug 2022 14:54:29 -0400 Received: by mail-pg1-f181.google.com with SMTP id 12so9378603pga.1 for <56002 <at> 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) MIME-Version: 1.0 References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> <8735e70xwl.fsf@HIDDEN> <831qtrvtg5.fsf@HIDDEN> In-Reply-To: <831qtrvtg5.fsf@HIDDEN> From: Tom Gillespie <tgbugs@HIDDEN> Date: Mon, 8 Aug 2022 11:54:09 -0700 Message-ID: <CA+G3_POmUnEozARB4WhLsM5esYOyQPKAKwPD7XxyZLRVWAZPCg@HIDDEN> Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56002 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > 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.
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 8 Aug 2022 11:57:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 08 07:57:56 2022 Received: from localhost ([127.0.0.1]:39388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oL1OO-0005jB-3r for submit <at> debbugs.gnu.org; Mon, 08 Aug 2022 07:57:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1oL1OJ-0005iv-NG for 56002 <at> debbugs.gnu.org; Mon, 08 Aug 2022 07:57:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1oL1OE-000855-Cb; Mon, 08 Aug 2022 07:57:46 -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=Co23mkXUQwijPVVm7mpHo443ijYsEVlseD2KEJgeJQk=; b=iUWoQG3xAwIb SCZcYeaq4oiL3L5zWoSn89u/UePldxIj9YncWFpeVR4fiLH9K63+7I3W3MMFev4DOmm2CPUdapNFc n7PKP27j9BmeB/54IisOSdD9Uk5Ilnfsm1EmAA7vLBS6PF5rbFXXHbO5Hf7akPJJ5Wiug5KXe4SEL 2AWg1xngI14kmUlyLow8NAIZrQfIvv4VZUxSpao31lrk65JLzbHG5Bj/AHpssTHTFgnbGUWbRoFaU F1wqlOL3gJBgTadVDzZ8w92+fIQRrkbWoC2jcd1J9FygMIH89pN0OrRp6DHbaAf2zgJBBVLH6oeqs yP+j0fm5xX0zoGs56dWIBA==; Received: from [87.69.77.57] (port=2917 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1oL1OB-0001t7-QI; Mon, 08 Aug 2022 07:57:46 -0400 Date: Mon, 08 Aug 2022 14:57:30 +0300 Message-Id: <831qtrvtg5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Lars Ingebrigtsen <larsi@HIDDEN> In-Reply-To: <8735e70xwl.fsf@HIDDEN> (message from Lars Ingebrigtsen on Mon, 08 Aug 2022 13:36:58 +0200) Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> <8735e70xwl.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56002 Cc: tgbugs@HIDDEN, 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen <larsi@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 56002 <at> debbugs.gnu.org > Date: Mon, 08 Aug 2022 13:36:58 +0200 > > Tom Gillespie <tgbugs@HIDDEN> writes: > > > * src/process.c (Fmake_process): Move the call to create the stderr > > process as late as possible to avoid having to clean up stderrproc in > > the event of an error prior to the call to create_process. This change > > is needed to ensure that when called with :query-stderr t (aka the > > default behavior prior to the addition of :query-stderr) make-process > > will not leak the stderr process if a call to make-process fails. > > Also adds a new keyword argument :query-stderr to control whether to > > query on exit the stderr process (if one is created). (bug#56002) > > I think this makes sense... Eli, any comments? 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? 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? 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?
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 8 Aug 2022 11:37:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 08 07:37:10 2022 Received: from localhost ([127.0.0.1]:39370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oL14I-0005Bm-4a for submit <at> debbugs.gnu.org; Mon, 08 Aug 2022 07:37:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1oL14G-0005Ba-Fq for 56002 <at> debbugs.gnu.org; Mon, 08 Aug 2022 07:37:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=70VI/9wFARy8je6sxz9cEFO1uGXl+pA0tPmqPshS7fA=; b=c4+2fp3JVMUrI0GiBrdcFg9WZ9 JyTY4dR2S4Yt2FaCaCb9wBDyLmk83LwL1fp6n7QYW6P/0PZHhGSVQHSa2OCLZ8+QjlXrxkKedShrr k7X8WMuKsLDevt2AMogmeYwuKKJcrZKs8+JiLJAXPF4GklrglJ7WHlDES0ED5eIQ78lw=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1oL147-00005h-GZ; Mon, 08 Aug 2022 13:37:01 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Tom Gillespie <tgbugs@HIDDEN> Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit In-Reply-To: <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> (Tom Gillespie's message of "Sun, 7 Aug 2022 16:48:44 -0700") References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> X-Now-Playing: Dzyan's _Deutsche Elektronische Music 4 (2)_: "Dragonsong" Date: Mon, 08 Aug 2022 13:36:58 +0200 Message-ID: <8735e70xwl.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Tom Gillespie <tgbugs@HIDDEN> writes: > * src/process.c (Fmake_process): Move the call to create the stderr > process as late as possible to avoid having to clean up stderrproc in > the event of an error prior to the call to create_proces [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56002 Cc: Eli Zaretskii <eliz@HIDDEN>, 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Tom Gillespie <tgbugs@HIDDEN> writes: > * src/process.c (Fmake_process): Move the call to create the stderr > process as late as possible to avoid having to clean up stderrproc in > the event of an error prior to the call to create_process. This change > is needed to ensure that when called with :query-stderr t (aka the > default behavior prior to the addition of :query-stderr) make-process > will not leak the stderr process if a call to make-process fails. > Also adds a new keyword argument :query-stderr to control whether to > query on exit the stderr process (if one is created). (bug#56002) I think this makes sense... Eli, any comments?
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 7 Aug 2022 23:49:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 07 19:49:07 2022 Received: from localhost ([127.0.0.1]:38558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oKq15-0001Hs-3E for submit <at> debbugs.gnu.org; Sun, 07 Aug 2022 19:49:07 -0400 Received: from mail-pj1-f50.google.com ([209.85.216.50]:37407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tgbugs@HIDDEN>) id 1oKq11-0001HM-1S for 56002 <at> debbugs.gnu.org; Sun, 07 Aug 2022 19:49:05 -0400 Received: by mail-pj1-f50.google.com with SMTP id w11-20020a17090a380b00b001f73f75a1feso2107588pjb.2 for <56002 <at> debbugs.gnu.org>; Sun, 07 Aug 2022 16:49:02 -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=wBJWB+jVLf+Sf/a7Ga4Z6PgH1SJgcBiI6KpxYvOdKCQ=; b=LcC1+w8bzZmyXNAm08JP11mjupeeQLEjLB2kGQ54telZc5uDMmK7C8okF0ieLsv3s0 /dJDKyZgyucjDiYyL8NEP2TXZJ180oN2DcWIZDnyv/Xq/rH+qZ/otcQ8Pgdnpc0Oqvi0 pI3ZQBR0CfCD/NtPdCOQTrQmVBvPI2eGNG4GSTrfHR+ZHrPi9SIJKM5g1nESRODqPaMq laRnqEfrIJPKTfN1oDBFoXCz9I8VZBaJ6i2dBhLNZp4VWr+mnTRSkrbZKwV+nIm9ioFU 303uTOClD0CbNl1CvyHUVqcJmONpxU2JVtGbWVMiW546A5pT9hm/b34dWuBe1QFVCO/t yyAQ== 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=wBJWB+jVLf+Sf/a7Ga4Z6PgH1SJgcBiI6KpxYvOdKCQ=; b=NFlqgWyJfwFeBkgK+M7Ikg4MyjdflIH4nwl1lSk1IF13coMgPyIABhk4pcI3lSj2g0 ZBU6qgLbjv+Do5FoWAiOYee/kvBct3gf31RVfYRoSLKHTcC/C1RoJ1tV6lE+YSb6YYf9 Jhq5s97vZ79CblIEfU3R6jS1f6IxlTLJABZTUtIfTFOkgjBbm0KWlVQTdM58UcmWHvJg HuAd9lJMA908EwASPOVtA85kyEwLP2aIfQx24EN7PXUpDwdSBubvmC0TzyGzWlplglrV EVhFCCr4dD8n4CWnxgn7qpfnneA25HqnwAVKUIMSLQwn60J7J0BY4kXCjpRR4nhcevxg c85w== X-Gm-Message-State: ACgBeo2St2sg4QyN5Yz2DVCrRrCfw7uZx/rSzLRK498qNc2A0iIlvC4O GZWHsjrC1mjOv0iWgvnCza/9+RWCaduert0z398= X-Google-Smtp-Source: AA6agR43ydRuaSG1uH9IpuuoGKd1oVTHxTosevgycjx3oaLExzUEY5m62/nryg5CdAspbGBTP8WSAsu2AGZWPw4xDpc= X-Received: by 2002:a17:903:2c6:b0:16d:d2c2:9939 with SMTP id s6-20020a17090302c600b0016dd2c29939mr16364765plk.42.1659916136887; Sun, 07 Aug 2022 16:48:56 -0700 (PDT) MIME-Version: 1.0 References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> In-Reply-To: <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> From: Tom Gillespie <tgbugs@HIDDEN> Date: Sun, 7 Aug 2022 16:48:44 -0700 Message-ID: <CA+G3_POV0zB11TFLcYtvHuMSB5Oou8tW1v6K50qbhWrv5f=aPQ@HIDDEN> Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/mixed; boundary="000000000000b27eab05e5af57ca" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56002 Cc: 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000b27eab05e5af57ca Content-Type: text/plain; charset="UTF-8" Here is an update to the 0002 patch to account for recent changes. --000000000000b27eab05e5af57ca Content-Type: text/x-patch; charset="US-ASCII"; name="0002-make-process-stderrproc-cleanup-on-failure-decouple-v2.patch" Content-Disposition: attachment; filename="0002-make-process-stderrproc-cleanup-on-failure-decouple-v2.patch" Content-Transfer-Encoding: base64 Content-ID: <f_l6jz76050> X-Attachment-Id: f_l6jz76050 RnJvbSBmODgzMDA0NTE4N2QyOGM5MGVlNjE2N2VhZmM3OWEwMDE5YzQxYWI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUb20gR2lsbGVzcGllIDx0Z2J1Z3NAZ21haWwuY29tPgpEYXRl OiBTdW4sIDcgQXVnIDIwMjIgMTY6NDM6MTMgLTA3MDAKU3ViamVjdDogW1BBVENIXSBtYWtlLXBy b2Nlc3Mgc3RkZXJycHJvYyBjbGVhbnVwIG9uIGZhaWx1cmUgZGVjb3VwbGUgc3RkZXJyCiBxdWVy eQoKKiBzcmMvcHJvY2Vzcy5jIChGbWFrZV9wcm9jZXNzKTogTW92ZSB0aGUgY2FsbCB0byBjcmVh dGUgdGhlIHN0ZGVycgpwcm9jZXNzIGFzIGxhdGUgYXMgcG9zc2libGUgdG8gYXZvaWQgaGF2aW5n IHRvIGNsZWFuIHVwIHN0ZGVycnByb2MgaW4KdGhlIGV2ZW50IG9mIGFuIGVycm9yIHByaW9yIHRv IHRoZSBjYWxsIHRvIGNyZWF0ZV9wcm9jZXNzLiBUaGlzIGNoYW5nZQppcyBuZWVkZWQgdG8gZW5z dXJlIHRoYXQgd2hlbiBjYWxsZWQgd2l0aCA6cXVlcnktc3RkZXJyIHQgKGFrYSB0aGUKZGVmYXVs dCBiZWhhdmlvciBwcmlvciB0byB0aGUgYWRkaXRpb24gb2YgOnF1ZXJ5LXN0ZGVycikgbWFrZS1w cm9jZXNzCndpbGwgbm90IGxlYWsgdGhlIHN0ZGVyciBwcm9jZXNzIGlmIGEgY2FsbCB0byBtYWtl LXByb2Nlc3MgZmFpbHMuCkFsc28gYWRkcyBhIG5ldyBrZXl3b3JkIGFyZ3VtZW50IDpxdWVyeS1z dGRlcnIgdG8gY29udHJvbCB3aGV0aGVyIHRvCnF1ZXJ5IG9uIGV4aXQgdGhlIHN0ZGVyciBwcm9j ZXNzIChpZiBvbmUgaXMgY3JlYXRlZCkuIChidWcjNTYwMDIpCgpOb3cgd2l0aCBjaGFuZ2VzIHRv IGFjY291bnQgZm9yIGludGVydmVuaW5nIGNoYW5nZXMgdG8gcHR5IGNvZGUuCi0tLQogc3JjL3By b2Nlc3MuYyB8IDQ1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0t LQogMSBmaWxlIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKyksIDE3IGRlbGV0aW9ucygtKQoKZGlm ZiAtLWdpdCBhL3NyYy9wcm9jZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IDIzNDc5YzA2MTku LjExZjg1YzVkMWQgMTAwNjQ0Ci0tLSBhL3NyYy9wcm9jZXNzLmMKKysrIGIvc3JjL3Byb2Nlc3Mu YwpAQCAtMTc2Miw2ICsxNzYyLDExIEBAIERFRlVOICgibWFrZS1wcm9jZXNzIiwgRm1ha2VfcHJv Y2VzcywgU21ha2VfcHJvY2VzcywgMCwgTUFOWSwgMCwKIDpub3F1ZXJ5IEJPT0wgLS0gV2hlbiBl eGl0aW5nIEVtYWNzLCBxdWVyeSB0aGUgdXNlciBpZiBCT09MIGlzIG5pbCBhbmQKIHRoZSBwcm9j ZXNzIGlzIHJ1bm5pbmcuICBJZiBCT09MIGlzIG5vdCBnaXZlbiwgcXVlcnkgYmVmb3JlIGV4aXRp bmcuCiAKKzpxdWVyeS1zdGRlcnIgQk9PTCAtLSBXaGVuIGV4aXRpbmcgRW1hY3MsIHF1ZXJ5IHRo ZSB1c2VyIGlmIEJPT0wgaXMKK25vbi1uaWwgYW5kIHRoZSBzdGRlcnIgcHJvY2VzcyBpcyBydW5u aW5nLiBJZiBCT09MIGlzIG5vdCBnaXZlbiwgZG8KK25vdCBxdWVyeSBiZWZvcmUgZXhpdGluZy4g VGhpcyBoYXMgbm8gZWZmZWN0IGlmIHRoZSB2YWx1ZSBwYXNzZWQgdG8KKzpzdGRlcnIgaXMgYSBw cm9jZXNzLgorCiA6c3RvcCBCT09MIC0tIEJPT0wgbXVzdCBiZSBuaWwuICBUaGUgYDpzdG9wJyBr ZXkgaXMgaWdub3JlZCBvdGhlcndpc2UKIGFuZCBpcyByZXRhaW5lZCBmb3IgY29tcGF0aWJpbGl0 eSB3aXRoIG90aGVyIHByb2Nlc3MgdHlwZXMgc3VjaCBhcwogcGlwZSBwcm9jZXNzZXMuICBBc3lu Y2hyb25vdXMgc3VicHJvY2Vzc2VzIG5ldmVyIHN0YXJ0IGluIHRoZQpAQCAtMTgzNyw4ICsxODQy LDYgQEAgREVGVU4gKCJtYWtlLXByb2Nlc3MiLCBGbWFrZV9wcm9jZXNzLCBTbWFrZV9wcm9jZXNz LCAwLCBNQU5ZLCAwLAogICBpZiAoIU5JTFAgKHByb2dyYW0pKQogICAgIENIRUNLX1NUUklORyAo cHJvZ3JhbSk7CiAKLSAgYm9vbCBxdWVyeV9vbl9leGl0ID0gTklMUCAocGxpc3RfZ2V0IChjb250 YWN0LCBRQ25vcXVlcnkpKTsKLQogICBzdGRlcnJwcm9jID0gUW5pbDsKICAgeHN0ZGVyciA9IHBs aXN0X2dldCAoY29udGFjdCwgUUNzdGRlcnIpOwogICBpZiAoUFJPQ0VTU1AgKHhzdGRlcnIpKQpA QCAtMTg0OCwxNiArMTg1MSw3IEBAIERFRlVOICgibWFrZS1wcm9jZXNzIiwgRm1ha2VfcHJvY2Vz cywgU21ha2VfcHJvY2VzcywgMCwgTUFOWSwgMCwKICAgICAgIHN0ZGVycnByb2MgPSB4c3RkZXJy OwogICAgIH0KICAgZWxzZSBpZiAoIU5JTFAgKHhzdGRlcnIpKQotICAgIHsKLSAgICAgIENIRUNL X1NUUklORyAocHJvZ3JhbSk7Ci0gICAgICBzdGRlcnJwcm9jID0gQ0FMTE4gKEZtYWtlX3BpcGVf cHJvY2VzcywKLQkJCSAgUUNuYW1lLAotCQkJICBjb25jYXQyIChuYW1lLCBidWlsZF9zdHJpbmcg KCIgc3RkZXJyIikpLAotCQkJICBRQ2J1ZmZlciwKLQkJCSAgRmdldF9idWZmZXJfY3JlYXRlICh4 c3RkZXJyLCBRbmlsKSwKLQkJCSAgUUNub3F1ZXJ5LAotCQkJICBxdWVyeV9vbl9leGl0ID8gUW5p bCA6IFF0KTsKLSAgICB9CisgICAgQ0hFQ0tfU1RSSU5HIChwcm9ncmFtKTsKIAogICBwcm9jID0g bWFrZV9wcm9jZXNzIChuYW1lKTsKICAgcmVjb3JkX3Vud2luZF9wcm90ZWN0IChzdGFydF9wcm9j ZXNzX3Vud2luZCwgcHJvYyk7CkBAIC0xODcwLDcgKzE4NjQsNyBAQCBERUZVTiAoIm1ha2UtcHJv Y2VzcyIsIEZtYWtlX3Byb2Nlc3MsIFNtYWtlX3Byb2Nlc3MsIDAsIE1BTlksIDAsCiAgIHBzZXRf ZmlsdGVyIChYUFJPQ0VTUyAocHJvYyksIHBsaXN0X2dldCAoY29udGFjdCwgUUNmaWx0ZXIpKTsK ICAgcHNldF9jb21tYW5kIChYUFJPQ0VTUyAocHJvYyksIEZjb3B5X3NlcXVlbmNlIChjb21tYW5k KSk7CiAKLSAgaWYgKCFxdWVyeV9vbl9leGl0KQorICBpZiAoIU5JTFAgKHBsaXN0X2dldCAoY29u dGFjdCwgUUNub3F1ZXJ5KSkpCiAgICAgWFBST0NFU1MgKHByb2MpLT5raWxsX3dpdGhvdXRfcXVl cnkgPSAxOwogICB0ZW0gPSBwbGlzdF9nZXQgKGNvbnRhY3QsIFFDc3RvcCk7CiAgIC8qIE5vcm1h bCBwcm9jZXNzZXMgY2FuJ3QgYmUgc3RhcnRlZCBpbiBhIHN0b3BwZWQgc3RhdGUsIHNlZQpAQCAt MTg4OSw5ICsxODgzLDYgQEAgREVGVU4gKCJtYWtlLXByb2Nlc3MiLCBGbWFrZV9wcm9jZXNzLCBT bWFrZV9wcm9jZXNzLCAwLCBNQU5ZLCAwLAogCWlzX3B0eV9mcm9tX3N5bWJvbCAodGVtKTsKICAg ICB9CiAKLSAgaWYgKCFOSUxQIChzdGRlcnJwcm9jKSkKLSAgICBwc2V0X3N0ZGVycnByb2MgKFhQ Uk9DRVNTIChwcm9jKSwgc3RkZXJycHJvYyk7Ci0KICNpZmRlZiBIQVZFX0dOVVRMUwogICAvKiBB S0EgR05VVExTX0lOSVRTVEFHRShwcm9jKS4gICovCiAgIHZlcmlmeSAoR05VVExTX1NUQUdFX0VN UFRZID09IDApOwpAQCAtMjA1NywxMCArMjA0OCwyOSBAQCBERUZVTiAoIm1ha2UtcHJvY2VzcyIs IEZtYWtlX3Byb2Nlc3MsIFNtYWtlX3Byb2Nlc3MsIDAsIE1BTlksIDAsCiAJICB0ZW0gPSBYQ0RS ICh0ZW0pOwogCX0KIAorICAgICAgaWYgKCFQUk9DRVNTUCAoeHN0ZGVycikgJiYgIU5JTFAgKHhz dGRlcnIpKQorCXsKKwkgIHN0ZGVycnByb2MgPSBDQUxMTiAoRm1ha2VfcGlwZV9wcm9jZXNzLAor CQkJICAgICAgUUNuYW1lLAorCQkJICAgICAgY29uY2F0MiAobmFtZSwgYnVpbGRfc3RyaW5nICgi IHN0ZGVyciIpKSwKKwkJCSAgICAgIFFDYnVmZmVyLAorCQkJICAgICAgRmdldF9idWZmZXJfY3Jl YXRlICh4c3RkZXJyLCBRbmlsKSwKKwkJCSAgICAgIFFDbm9xdWVyeSwKKwkJCSAgICAgIE5JTFAg KHBsaXN0X2dldCAoY29udGFjdCwgUUNxdWVyeV9zdGRlcnIpKSA/IFF0IDogUW5pbCk7CisJfQor CisgICAgICBpZiAoIU5JTFAgKHN0ZGVycnByb2MpKQorCXBzZXRfc3RkZXJycHJvYyAoWFBST0NF U1MgKHByb2MpLCBzdGRlcnJwcm9jKTsKKwogICAgICAgY3JlYXRlX3Byb2Nlc3MgKHByb2MsIG5l d19hcmd2LCBjdXJyZW50X2Rpcik7CiAgICAgfQogICBlbHNlCi0gICAgY3JlYXRlX3B0eSAocHJv Yyk7CisgICAgeworICAgICAgaWYgKCFOSUxQIChzdGRlcnJwcm9jKSkKKwlwc2V0X3N0ZGVycnBy b2MgKFhQUk9DRVNTIChwcm9jKSwgc3RkZXJycHJvYyk7CisKKyAgICAgIGNyZWF0ZV9wdHkgKHBy b2MpOworICAgIH0KIAogICByZXR1cm4gU0FGRV9GUkVFX1VOQklORF9UTyAoY291bnQsIHByb2Mp OwogfQpAQCAtODYwOSw2ICs4NjE5LDcgQEAgc3ltc19vZl9wcm9jZXNzICh2b2lkKQogICBERUZT WU0gKFFuc21fdmVyaWZ5X2Nvbm5lY3Rpb24sICJuc20tdmVyaWZ5LWNvbm5lY3Rpb24iKTsKICAg REVGU1lNIChRQ2xvZywgIjpsb2ciKTsKICAgREVGU1lNIChRQ25vcXVlcnksICI6bm9xdWVyeSIp OworICBERUZTWU0gKFFDcXVlcnlfc3RkZXJyLCAiOnF1ZXJ5LXN0ZGVyciIpOwogICBERUZTWU0g KFFDc3RvcCwgIjpzdG9wIik7CiAgIERFRlNZTSAoUUNwbGlzdCwgIjpwbGlzdCIpOwogICBERUZT WU0gKFFDY29tbWFuZCwgIjpjb21tYW5kIik7Ci0tIAoyLjM1LjEKCg== --000000000000b27eab05e5af57ca--
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 29 Jun 2022 21:18:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 29 17:18:03 2022 Received: from localhost ([127.0.0.1]:60357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1o6f4U-0005vo-CT for submit <at> debbugs.gnu.org; Wed, 29 Jun 2022 17:18:02 -0400 Received: from mail-io1-f47.google.com ([209.85.166.47]:38877) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tgbugs@HIDDEN>) id 1o6f4R-0005vH-AP for 56002 <at> debbugs.gnu.org; Wed, 29 Jun 2022 17:18:01 -0400 Received: by mail-io1-f47.google.com with SMTP id k15so17282834iok.5 for <56002 <at> debbugs.gnu.org>; Wed, 29 Jun 2022 14:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H9P6OnouvejPPK+jXDx9t1rgGFLTLciQ/+xdGW1VtP0=; b=pzxjD3wMKRXxmcUx4AMIo1T1rUxhG8gzC5kQDrTw7O5cCxn0DkDAzmYaxbNxVICtOp IzvV/bDGaysDGvQ1J4p31nLVMVgMobTYH18Q+dIElngltDYb4omrFWUQADAONSCFC4NB 8JdZJoUCxcrRvwkl0+v9UaCTgLoOEAd9bhqCrwlcenmvdl0ODEFTom8aPKRrvejUoISh E8O3JEFJNCQpX/eJNATVv9s1r88qrFcUzC7EiKoU343WMCe6aMBmqqG+lcFtt72vdBZY SgMVsKf7vVgS17yIsIo2xgWrtjws6UtzsfaEMAAaTfmVoNb5Xzy61/jbFr6d2cyzvc7P Muqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H9P6OnouvejPPK+jXDx9t1rgGFLTLciQ/+xdGW1VtP0=; b=okrtQdESCjkfniG7ecMqNFZDeDgw7dc0Ge7lw1xgttMpAt6TIOY/sxY7JxUj2Ejxf4 98GT19Gu3c/93LxNSCRAOEXlQl3Gulf9jNy+JLcArH/auQ6ou3JDv94HQNHVItkkxlig Zo14+DJktbKEO9ijPJlPG556RUB1FiXzUB80fRnAIYHC4Ey8e9fhJ1k50FELxJ0mszzB cf/ATSDePEvbo2MtmXy6XhMje7xgvP3yOilR8T89K3FkkqXuLZOGsIrtTqwozvh1Xjtd JVqHoIGu9BgFzKQZRZC3ljiiMTteeWYhtlch3EFtEvI4lOTbbJfVOHO+c/zj8huh6qK/ wuZQ== X-Gm-Message-State: AJIora/dklqZCYCVoEVCR4/92Wdsn+VYB7QSc0ncSvp4XD3B0lYzfbVH 6Uz+WdqHcKjqj3SaSk8MswFEja9tL2JKF9PBkYk4D50WzCk= X-Google-Smtp-Source: AGRyM1uquutjER+8ZVQwvEoK/wPhqAiY/ojKMNjUA+N9ZCmaGa/X9tVRO6pnGbQBzyqLW555ZOGosq5FGwUuqAQgDx8= X-Received: by 2002:a02:a08d:0:b0:33c:6a7d:87db with SMTP id g13-20020a02a08d000000b0033c6a7d87dbmr3138047jah.64.1656537473637; Wed, 29 Jun 2022 14:17:53 -0700 (PDT) MIME-Version: 1.0 References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> In-Reply-To: <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> From: Tom Gillespie <tgbugs@HIDDEN> Date: Wed, 29 Jun 2022 14:17:42 -0700 Message-ID: <CA+G3_PPtJd9L+FWTPBkhKcs0fPAcTqRQzw54oG66fLHrC5mrsQ@HIDDEN> Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/mixed; boundary="000000000000ac7b6b05e29cafa9" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56002 Cc: 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000ac7b6b05e29cafa9 Content-Type: text/plain; charset="UTF-8" After digging deep into this I think I have a solution. It is attached as two patches, one that adds tests and one that updates Fmake_proc. For the record, there was not a missing unwind-protect. There are two changes to the implementation that are complementary. The first is to change the internal structure of Fmake_process so that stderrproc is created immediately before the call to create_process. This avoids the need to call remove_process on stderrproc in the event of any expected or unexpected exits prior to the call to create process. This resolves the issue as originally described. The second change is to decouple the query-on-exit behavior of stderrproc from that of proc by adding a new keyword argument :query-stderr which defaults to nil. The coupling of query-on-exit for proc and stderrproc in the currently implementation forces users to always add additional boilerplate specifically when they don't care about stderr, which is the opposite of what would want (forcing callers who don't care about something to handle it, rather than the other way around). In addition to the patches, I have a question about an inconsistency in the documentation, and a suggestion about how it might be resolved. I can open this as a new issue if that makes more sense. One thing I don't understand is the interaction between :command '(nil) and :stderr a-pipe-process. It seems that the behaviors described by their documentation should be mutually exclusive, but make-process creates a pty without complaining. I suggest that either an error be raised if :command '(nil) and :stderr a-pipe-process are provided at the same time, because in all other cases for :stderr there is a call to CHECK_STRING that will cause an error, and it is not clear why the pipe process variant should be exempt from this check since it does not appear that the stderr pipe process is ever hooked up to the pty. Any insights here would be appreciated. At the very least the documentation for :connection-type needs to be updated to correct the following, since it does not match the current implemented behavior > if a non-nil value is specified for the :stderr parameter ... the type will always be pipe As it stands I think I have preserved existing behavior with some slight code duplication that reflects the confusion about what should happens when a stderr process is provided and create_pty is called instead of create_process. --000000000000ac7b6b05e29cafa9 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-test-src-process-tests.el-test-make-process-stderr-q.patch" Content-Disposition: attachment; filename="0001-test-src-process-tests.el-test-make-process-stderr-q.patch" Content-Transfer-Encoding: base64 Content-ID: <f_l503j6ix1> X-Attachment-Id: f_l503j6ix1 RnJvbSAyYjBkM2QyYWE4ODZhNDgyYmIwZTU1NDZlYzI3ZmVmNDdmOWQzNGIwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUb20gR2lsbGVzcGllIDx0Z2J1Z3NAZ21haWwuY29tPgpEYXRl OiBXZWQsIDI5IEp1biAyMDIyIDEzOjI2OjA2IC0wNzAwClN1YmplY3Q6IFtQQVRDSCAxLzJdIHRl c3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWw6IHRlc3QgbWFrZS1wcm9jZXNzIHN0ZGVycgogcXVlcnkv Y2xlYW51cAoKKiB0ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVsIChtYWtlLXByb2Nlc3MvcXVlcnkt c3RkZXJyKTogQWRkZWQgdG8KZW5zdXJlIDpxdWVyeS1zdGRlcnIgYmVoYXZlcyBhcyBleHBlY3Rl ZC4KCiogdGVzdC9zcmMvcHJvY2Vzcy10ZXN0cy5lbCAobWFrZS1wcm9jZXNzL2NsZWFudXAtc3Rk ZXJycHJvYyk6IEFkZGVkCnRvIGVuc3VyZSB0aGF0IG1ha2UtcHJvY2VzcyBjb3JyZWN0bHkgY2xl YW5zIHVwL25ldmVyIGNyZWF0ZXMKc3RkZXJycHJvYyBpbiB0aGUgZXZlbnQgb2YgYW4gZWFybHkg ZXhpdC9lcnJvci4KLS0tCiB0ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVsIHwgNjUgKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgNjUgaW5zZXJ0 aW9ucygrKQoKZGlmZiAtLWdpdCBhL3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwgYi90ZXN0L3Ny Yy9wcm9jZXNzLXRlc3RzLmVsCmluZGV4IDgyNGM2ZGExMTkuLjUwMTU5YWI0NmIgMTAwNjQ0Ci0t LSBhL3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwKKysrIGIvdGVzdC9zcmMvcHJvY2Vzcy10ZXN0 cy5lbApAQCAtMjMzLDYgKzIzMyw3MSBAQCBtYWtlLXByb2Nlc3Mvbm9xdWVyeS1zdGRlcnIKICAg ICAgICAgICAgICAgKHNob3VsZC1ub3QgKHByb2Nlc3MtcXVlcnktb24tZXhpdC1mbGFnIHByb2Nl c3MpKSkpCiAgICAgICAgIChraWxsLXByb2Nlc3MgcHJvY2VzcykpKSkpKQogCisoZXJ0LWRlZnRl c3QgbWFrZS1wcm9jZXNzL3F1ZXJ5LXN0ZGVyciAoKQorICAoc2tpcC11bmxlc3MgKGV4ZWN1dGFi bGUtZmluZCAiYmFzaCIpKQorICAobGV0ICgoc3RkZXJyLWJ1ZmZlciAoZ2VuZXJhdGUtbmV3LWJ1 ZmZlciAiIHJjIHN0ZGVyciIpKSkKKyAgICAodW53aW5kLXByb3RlY3QKKyAgICAgICAgKGxldCAo KHByb2Nlc3MKKyAgICAgICAgICAgICAgIChtYWtlLXByb2Nlc3MKKyAgICAgICAgICAgICAgICA6 bmFtZSAicHJvY2VzcyB0aGF0IG5ldmVyIGFjdHVhbGx5IHN0YXJ0cyIKKyAgICAgICAgICAgICAg ICA6c3RkZXJyIHN0ZGVyci1idWZmZXIKKyAgICAgICAgICAgICAgICA6Y29tbWFuZCAnKCJiYXNo IiAiLWMiICJlY2hvIHN0ZG91dDsgZWNobyBzdGRlcnIgMT4mMjsiKSkpKQorICAgICAgICAgICh3 aGlsZSAoYWNjZXB0LXByb2Nlc3Mtb3V0cHV0IChnZXQtYnVmZmVyLXByb2Nlc3MgKHByb2Nlc3Mt YnVmZmVyIHByb2Nlc3MpKSkpKQorICAgICAgKGxldCAoKHN0ZGVycnByb2MgKGdldC1idWZmZXIt cHJvY2VzcyBzdGRlcnItYnVmZmVyKSkpCisgICAgICAgIChzaG91bGQgc3RkZXJycHJvYykKKyAg ICAgICAgKHNob3VsZC1ub3QgKHByb2Nlc3MtcXVlcnktb24tZXhpdC1mbGFnIHN0ZGVycnByb2Mp KSkKKyAgICAgIChzaG91bGQgKGdldC1idWZmZXItcHJvY2VzcyBzdGRlcnItYnVmZmVyKSkKKyAg ICAgIChraWxsLWJ1ZmZlciBzdGRlcnItYnVmZmVyKSkKKyAgICAoc2hvdWxkLW5vdCAoYnVmZmVy LWxpdmUtcCBzdGRlcnItYnVmZmVyKSkpCisKKyAgKGxldCAoKHN0ZGVyci1idWZmZXIgKGdlbmVy YXRlLW5ldy1idWZmZXIgIiByYyBzdGRlcnIiKSkpCisgICAgKHVud2luZC1wcm90ZWN0CisgICAg ICAgIChsZXQgKChwcm9jZXNzCisgICAgICAgICAgICAgICAobWFrZS1wcm9jZXNzCisgICAgICAg ICAgICAgICAgOm5hbWUgInByb2Nlc3MgdGhhdCBuZXZlciBhY3R1YWxseSBzdGFydHMiCisgICAg ICAgICAgICAgICAgOnN0ZGVyciBzdGRlcnItYnVmZmVyCisgICAgICAgICAgICAgICAgOnF1ZXJ5 LXN0ZGVyciB0CisgICAgICAgICAgICAgICAgOmNvbW1hbmQgJygiYmFzaCIgIi1jIiAiZWNobyBz dGRvdXQ7IGVjaG8gc3RkZXJyIDE+JjI7IikpKSkKKyAgICAgICAgICAod2hpbGUgKGFjY2VwdC1w cm9jZXNzLW91dHB1dCAoZ2V0LWJ1ZmZlci1wcm9jZXNzIChwcm9jZXNzLWJ1ZmZlciBwcm9jZXNz KSkpKSkKKyAgICAgIChsZXQgKChzdGRlcnJwcm9jIChnZXQtYnVmZmVyLXByb2Nlc3Mgc3RkZXJy LWJ1ZmZlcikpKQorICAgICAgICAoc2hvdWxkIHN0ZGVycnByb2MpCisgICAgICAgIChzaG91bGQg KHByb2Nlc3MtcXVlcnktb24tZXhpdC1mbGFnIHN0ZGVycnByb2MpKSkKKyAgICAgICh3aGlsZSAo YWNjZXB0LXByb2Nlc3Mtb3V0cHV0IChnZXQtYnVmZmVyLXByb2Nlc3Mgc3RkZXJyLWJ1ZmZlcikp KQorICAgICAgKHNob3VsZC1ub3QgKGdldC1idWZmZXItcHJvY2VzcyBzdGRlcnItYnVmZmVyKSkK KyAgICAgIChraWxsLWJ1ZmZlciBzdGRlcnItYnVmZmVyKSkKKyAgICAoc2hvdWxkLW5vdCAoYnVm ZmVyLWxpdmUtcCBzdGRlcnItYnVmZmVyKSkpKQorCisoZXJ0LWRlZnRlc3QgbWFrZS1wcm9jZXNz L2NsZWFudXAtc3RkZXJycHJvYyAoKQorICAiZW5zdXJlIHN0ZGVycnByb2MgaXMgY2xlYW5lZCB1 cC9uZXZlciBjcmVhdGVkIGlmIGBtYWtlLXByb2Nlc3MnIGZhaWxzIgorICAoc2hvdWxkLWVycm9y CisgICAobGV0ICgoc3RkZXJyLWJ1ZmZlciAoZ2VuZXJhdGUtbmV3LWJ1ZmZlciAiIHJjIHN0ZGVy ciIpKSkKKyAgICAgKHVud2luZC1wcm90ZWN0CisgICAgICAgICAobGV0ICgocHJvY2VzcworICAg ICAgICAgICAgICAgIChtYWtlLXByb2Nlc3MKKyAgICAgICAgICAgICAgICAgOm5hbWUgInByb2Nl c3MgdGhhdCBuZXZlciBhY3R1YWxseSBzdGFydHMiCisgICAgICAgICAgICAgICAgIDpzdGRlcnIg c3RkZXJyLWJ1ZmZlcgorICAgICAgICAgICAgICAgICA6cXVlcnktc3RkZXJyIHQKKyAgICAgICAg ICAgICAgICAgOmNvbW1hbmQgJygiaV9mYWlsX2JlZm9yZV90aGVyZV9jYW5fYmVfYV9yZXR1cm5f Y29kZSIpKSkpKQorICAgICAgIChzaG91bGQtbm90IChnZXQtYnVmZmVyLXByb2Nlc3Mgc3RkZXJy LWJ1ZmZlcikpCisgICAgICAgKGtpbGwtYnVmZmVyIHN0ZGVyci1idWZmZXIpKQorICAgICAoc2hv dWxkLW5vdCAoYnVmZmVyLWxpdmUtcCBzdGRlcnItYnVmZmVyKSkpKQorCisgIChzaG91bGQtZXJy b3IKKyAgIChsZXQgKChzdGRlcnItYnVmZmVyIChnZW5lcmF0ZS1uZXctYnVmZmVyICIgcmMgc3Rk ZXJyIikpKQorICAgICAodW53aW5kLXByb3RlY3QKKyAgICAgICAgIChsZXQgKChwcm9jZXNzCisg ICAgICAgICAgICAgICAgKG1ha2UtcHJvY2VzcworICAgICAgICAgICAgICAgICA6bmFtZSAicHJv Y2VzcyB0aGF0IG5ldmVyIGFjdHVhbGx5IHN0YXJ0cyIKKyAgICAgICAgICAgICAgICAgOnN0ZGVy ciBzdGRlcnItYnVmZmVyCisgICAgICAgICAgICAgICAgIDpxdWVyeS1zdGRlcnIgdAorICAgICAg ICAgICAgICAgICA6Y29tbWFuZCAnKCJpX2ZhaWxfYmVmb3JlX3RoZXJlX2Nhbl9iZV9hX3JldHVy bl9jb2RlIikpKSkKKyAgICAgICAgICAgKG1lc3NhZ2UgInRoaXMgd2lsbCBuZXZlciBwcmludCBi ZWNhdXNlIHdlIG5ldmVyIGdldCBoZXJlIikKKyAgICAgICAgICAgKHdoaWxlIChhY2NlcHQtcHJv Y2Vzcy1vdXRwdXQgcHJvY2VzcykpKQorICAgICAgIChzaG91bGQtbm90IChnZXQtYnVmZmVyLXBy b2Nlc3Mgc3RkZXJyLWJ1ZmZlcikpCisgICAgICAgKHdoaWxlIChhY2NlcHQtcHJvY2Vzcy1vdXRw dXQgKGdldC1idWZmZXItcHJvY2VzcyBzdGRlcnItYnVmZmVyKSkpCisgICAgICAgKGtpbGwtYnVm ZmVyIHN0ZGVyci1idWZmZXIpKQorICAgICAoc2hvdWxkLW5vdCAoYnVmZmVyLWxpdmUtcCBzdGRl cnItYnVmZmVyKSkpKSkKKwogOzsgUmV0dXJuIHQgaWYgT1VUUFVUIGNvdWxkIGhhdmUgYmVlbiBn ZW5lcmF0ZWQgYnkgbWVyZ2luZyB0aGUgSU5QVVRTIHNvbWVob3cuCiAoZGVmdW4gcHJvY2Vzcy10 ZXN0cy0tbWl4YWJsZSAob3V0cHV0ICZyZXN0IGlucHV0cykKICAgKHdoaWxlIChhbmQgb3V0cHV0 IChsZXQgKChpbnMgaW5wdXRzKSkKLS0gCjIuMzUuMQoK --000000000000ac7b6b05e29cafa9 Content-Type: text/x-patch; charset="US-ASCII"; name="0002-make-process-stderrproc-cleanup-on-failure-decouple-.patch" Content-Disposition: attachment; filename="0002-make-process-stderrproc-cleanup-on-failure-decouple-.patch" Content-Transfer-Encoding: base64 Content-ID: <f_l503jb1j1> X-Attachment-Id: f_l503jb1j1 RnJvbSAwN2ExZmEzNGVkZjA2N2VhYmY3MjZiOWI0NGVmMDhiZjY3NzcxYzYwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUb20gR2lsbGVzcGllIDx0Z2J1Z3NAZ21haWwuY29tPgpEYXRl OiBXZWQsIDI5IEp1biAyMDIyIDEzOjQ4OjA5IC0wNzAwClN1YmplY3Q6IFtQQVRDSCAyLzJdIG1h a2UtcHJvY2VzcyBzdGRlcnJwcm9jIGNsZWFudXAgb24gZmFpbHVyZSBkZWNvdXBsZQogc3RkZXJy IHF1ZXJ5CgoqIHNyYy9wcm9jZXNzLmMgKEZtYWtlX3Byb2Nlc3MpOiBNb3ZlIHRoZSBjYWxsIHRv IGNyZWF0ZSB0aGUgc3RkZXJyCnByb2Nlc3MgYXMgbGF0ZSBhcyBwb3NzaWJsZSB0byBhdm9pZCBo YXZpbmcgdG8gY2xlYW4gdXAgc3RkZXJycHJvYyBpbgp0aGUgZXZlbnQgb2YgYW4gZXJyb3IgcHJp b3IgdG8gdGhlIGNhbGwgdG8gY3JlYXRlX3Byb2Nlc3MuIFRoaXMgY2hhbmdlCmlzIG5lZWRlZCB0 byBlbnN1cmUgdGhhdCB3aGVuIGNhbGxlZCB3aXRoIDpxdWVyeS1zdGRlcnIgdCAoYWthIHRoZQpk ZWZhdWx0IGJlaGF2aW9yIHByaW9yIHRvIHRoZSBhZGRpdGlvbiBvZiA6cXVlcnktc3RkZXJyKSBt YWtlLXByb2Nlc3MKd2lsbCBub3QgbGVhayB0aGUgc3RkZXJyIHByb2Nlc3MgaWYgYSBjYWxsIHRv IG1ha2UtcHJvY2VzcyBmYWlscy4KQWxzbyBhZGRzIGEgbmV3IGtleXdvcmQgYXJndW1lbnQgOnF1 ZXJ5LXN0ZGVyciB0byBjb250cm9sIHdoZXRoZXIgdG8KcXVlcnkgb24gZXhpdCB0aGUgc3RkZXJy IHByb2Nlc3MgKGlmIG9uZSBpcyBjcmVhdGVkKS4gKGJ1ZyM1NjAwMikKLS0tCiBzcmMvcHJvY2Vz cy5jIHwgNTcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgMzYgaW5zZXJ0aW9ucygrKSwgMjEgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvc3JjL3Byb2Nlc3MuYyBiL3NyYy9wcm9jZXNzLmMKaW5kZXggYWY0MDJjOGVk Yi4uYzA4ZGQ2OTk1YSAxMDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9zcmMvcHJvY2Vz cy5jCkBAIC0xNzMyLDYgKzE3MzIsMTEgQEAgREVGVU4gKCJtYWtlLXByb2Nlc3MiLCBGbWFrZV9w cm9jZXNzLCBTbWFrZV9wcm9jZXNzLCAwLCBNQU5ZLCAwLAogOm5vcXVlcnkgQk9PTCAtLSBXaGVu IGV4aXRpbmcgRW1hY3MsIHF1ZXJ5IHRoZSB1c2VyIGlmIEJPT0wgaXMgbmlsIGFuZAogdGhlIHBy b2Nlc3MgaXMgcnVubmluZy4gIElmIEJPT0wgaXMgbm90IGdpdmVuLCBxdWVyeSBiZWZvcmUgZXhp dGluZy4KIAorOnF1ZXJ5LXN0ZGVyciBCT09MIC0tIFdoZW4gZXhpdGluZyBFbWFjcywgcXVlcnkg dGhlIHVzZXIgaWYgQk9PTCBpcworbm9uLW5pbCBhbmQgdGhlIHN0ZGVyciBwcm9jZXNzIGlzIHJ1 bm5pbmcuIElmIEJPT0wgaXMgbm90IGdpdmVuLCBkbworbm90IHF1ZXJ5IGJlZm9yZSBleGl0aW5n LiBUaGlzIGhhcyBubyBlZmZlY3QgaWYgdGhlIHZhbHVlIHBhc3NlZCB0bworOnN0ZGVyciBpcyBh IHByb2Nlc3MuCisKIDpzdG9wIEJPT0wgLS0gQk9PTCBtdXN0IGJlIG5pbC4gIFRoZSBgOnN0b3An IGtleSBpcyBpZ25vcmVkIG90aGVyd2lzZQogYW5kIGlzIHJldGFpbmVkIGZvciBjb21wYXRpYmls aXR5IHdpdGggb3RoZXIgcHJvY2VzcyB0eXBlcyBzdWNoIGFzCiBwaXBlIHByb2Nlc3Nlcy4gIEFz eW5jaHJvbm91cyBzdWJwcm9jZXNzZXMgbmV2ZXIgc3RhcnQgaW4gdGhlCkBAIC0xODA0LDggKzE4 MDksNiBAQCBERUZVTiAoIm1ha2UtcHJvY2VzcyIsIEZtYWtlX3Byb2Nlc3MsIFNtYWtlX3Byb2Nl c3MsIDAsIE1BTlksIDAsCiAgIGlmICghTklMUCAocHJvZ3JhbSkpCiAgICAgQ0hFQ0tfU1RSSU5H IChwcm9ncmFtKTsKIAotICBib29sIHF1ZXJ5X29uX2V4aXQgPSBOSUxQIChwbGlzdF9nZXQgKGNv bnRhY3QsIFFDbm9xdWVyeSkpOwotCiAgIHN0ZGVycnByb2MgPSBRbmlsOwogICB4c3RkZXJyID0g cGxpc3RfZ2V0IChjb250YWN0LCBRQ3N0ZGVycik7CiAgIGlmIChQUk9DRVNTUCAoeHN0ZGVycikp CkBAIC0xODE1LDE2ICsxODE4LDcgQEAgREVGVU4gKCJtYWtlLXByb2Nlc3MiLCBGbWFrZV9wcm9j ZXNzLCBTbWFrZV9wcm9jZXNzLCAwLCBNQU5ZLCAwLAogICAgICAgc3RkZXJycHJvYyA9IHhzdGRl cnI7CiAgICAgfQogICBlbHNlIGlmICghTklMUCAoeHN0ZGVycikpCi0gICAgewotICAgICAgQ0hF Q0tfU1RSSU5HIChwcm9ncmFtKTsKLSAgICAgIHN0ZGVycnByb2MgPSBDQUxMTiAoRm1ha2VfcGlw ZV9wcm9jZXNzLAotCQkJICBRQ25hbWUsCi0JCQkgIGNvbmNhdDIgKG5hbWUsIGJ1aWxkX3N0cmlu ZyAoIiBzdGRlcnIiKSksCi0JCQkgIFFDYnVmZmVyLAotCQkJICBGZ2V0X2J1ZmZlcl9jcmVhdGUg KHhzdGRlcnIsIFFuaWwpLAotCQkJICBRQ25vcXVlcnksCi0JCQkgIHF1ZXJ5X29uX2V4aXQgPyBR bmlsIDogUXQpOwotICAgIH0KKyAgICBDSEVDS19TVFJJTkcgKHByb2dyYW0pOwogCiAgIHByb2Mg PSBtYWtlX3Byb2Nlc3MgKG5hbWUpOwogICByZWNvcmRfdW53aW5kX3Byb3RlY3QgKHN0YXJ0X3By b2Nlc3NfdW53aW5kLCBwcm9jKTsKQEAgLTE4MzcsNyArMTgzMSw3IEBAIERFRlVOICgibWFrZS1w cm9jZXNzIiwgRm1ha2VfcHJvY2VzcywgU21ha2VfcHJvY2VzcywgMCwgTUFOWSwgMCwKICAgcHNl dF9maWx0ZXIgKFhQUk9DRVNTIChwcm9jKSwgcGxpc3RfZ2V0IChjb250YWN0LCBRQ2ZpbHRlcikp OwogICBwc2V0X2NvbW1hbmQgKFhQUk9DRVNTIChwcm9jKSwgRmNvcHlfc2VxdWVuY2UgKGNvbW1h bmQpKTsKIAotICBpZiAoIXF1ZXJ5X29uX2V4aXQpCisgIGlmICghTklMUCAocGxpc3RfZ2V0IChj b250YWN0LCBRQ25vcXVlcnkpKSkKICAgICBYUFJPQ0VTUyAocHJvYyktPmtpbGxfd2l0aG91dF9x dWVyeSA9IDE7CiAgIHRlbSA9IHBsaXN0X2dldCAoY29udGFjdCwgUUNzdG9wKTsKICAgLyogTm9y bWFsIHByb2Nlc3NlcyBjYW4ndCBiZSBzdGFydGVkIGluIGEgc3RvcHBlZCBzdGF0ZSwgc2VlCkBA IC0xODU0LDEzICsxODQ4LDYgQEAgREVGVU4gKCJtYWtlLXByb2Nlc3MiLCBGbWFrZV9wcm9jZXNz LCBTbWFrZV9wcm9jZXNzLCAwLCBNQU5ZLCAwLAogICBlbHNlCiAgICAgcmVwb3J0X2ZpbGVfZXJy b3IgKCJVbmtub3duIGNvbm5lY3Rpb24gdHlwZSIsIHRlbSk7CiAKLSAgaWYgKCFOSUxQIChzdGRl cnJwcm9jKSkKLSAgICB7Ci0gICAgICBwc2V0X3N0ZGVycnByb2MgKFhQUk9DRVNTIChwcm9jKSwg c3RkZXJycHJvYyk7Ci0KLSAgICAgIFhQUk9DRVNTIChwcm9jKS0+cHR5X2ZsYWcgPSBmYWxzZTsK LSAgICB9Ci0KICNpZmRlZiBIQVZFX0dOVVRMUwogICAvKiBBS0EgR05VVExTX0lOSVRTVEFHRShw cm9jKS4gICovCiAgIHZlcmlmeSAoR05VVExTX1NUQUdFX0VNUFRZID09IDApOwpAQCAtMjAyNiwx MCArMjAxMywzNyBAQCBERUZVTiAoIm1ha2UtcHJvY2VzcyIsIEZtYWtlX3Byb2Nlc3MsIFNtYWtl X3Byb2Nlc3MsIDAsIE1BTlksIDAsCiAJICB0ZW0gPSBYQ0RSICh0ZW0pOwogCX0KIAorICAgICAg aWYgKCFQUk9DRVNTUCAoeHN0ZGVycikgJiYgIU5JTFAgKHhzdGRlcnIpKQorCXsKKwkgIHN0ZGVy cnByb2MgPSBDQUxMTiAoRm1ha2VfcGlwZV9wcm9jZXNzLAorCQkJICAgICAgUUNuYW1lLAorCQkJ ICAgICAgY29uY2F0MiAobmFtZSwgYnVpbGRfc3RyaW5nICgiIHN0ZGVyciIpKSwKKwkJCSAgICAg IFFDYnVmZmVyLAorCQkJICAgICAgRmdldF9idWZmZXJfY3JlYXRlICh4c3RkZXJyLCBRbmlsKSwK KwkJCSAgICAgIFFDbm9xdWVyeSwKKwkJCSAgICAgIE5JTFAgKHBsaXN0X2dldCAoY29udGFjdCwg UUNxdWVyeV9zdGRlcnIpKSA/IFF0IDogUW5pbCk7CisJfQorCisgICAgICBpZiAoIU5JTFAgKHN0 ZGVycnByb2MpKQorCXsKKwkgIHBzZXRfc3RkZXJycHJvYyAoWFBST0NFU1MgKHByb2MpLCBzdGRl cnJwcm9jKTsKKworCSAgWFBST0NFU1MgKHByb2MpLT5wdHlfZmxhZyA9IGZhbHNlOworCX0KKwog ICAgICAgY3JlYXRlX3Byb2Nlc3MgKHByb2MsIG5ld19hcmd2LCBjdXJyZW50X2Rpcik7CiAgICAg fQogICBlbHNlCi0gICAgY3JlYXRlX3B0eSAocHJvYyk7CisgICAgeworICAgICAgaWYgKCFOSUxQ IChzdGRlcnJwcm9jKSkKKwl7CisJICBwc2V0X3N0ZGVycnByb2MgKFhQUk9DRVNTIChwcm9jKSwg c3RkZXJycHJvYyk7CisKKwkgIFhQUk9DRVNTIChwcm9jKS0+cHR5X2ZsYWcgPSBmYWxzZTsKKwl9 CisKKyAgICAgIGNyZWF0ZV9wdHkgKHByb2MpOworICAgIH0KIAogICByZXR1cm4gU0FGRV9GUkVF X1VOQklORF9UTyAoY291bnQsIHByb2MpOwogfQpAQCAtODU0Myw2ICs4NTU3LDcgQEAgc3ltc19v Zl9wcm9jZXNzICh2b2lkKQogICBERUZTWU0gKFFuc21fdmVyaWZ5X2Nvbm5lY3Rpb24sICJuc20t dmVyaWZ5LWNvbm5lY3Rpb24iKTsKICAgREVGU1lNIChRQ2xvZywgIjpsb2ciKTsKICAgREVGU1lN IChRQ25vcXVlcnksICI6bm9xdWVyeSIpOworICBERUZTWU0gKFFDcXVlcnlfc3RkZXJyLCAiOnF1 ZXJ5LXN0ZGVyciIpOwogICBERUZTWU0gKFFDc3RvcCwgIjpzdG9wIik7CiAgIERFRlNZTSAoUUNw bGlzdCwgIjpwbGlzdCIpOwogICBERUZTWU0gKFFDY29tbWFuZCwgIjpjb21tYW5kIik7Ci0tIAoy LjM1LjEKCg== --000000000000ac7b6b05e29cafa9--
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.Received: (at 56002) by debbugs.gnu.org; 16 Jun 2022 06:12:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 16 02:12:10 2022 Received: from localhost ([127.0.0.1]:40482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1o1iji-0003LW-Jr for submit <at> debbugs.gnu.org; Thu, 16 Jun 2022 02:12:10 -0400 Received: from mail-yw1-f172.google.com ([209.85.128.172]:42722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tgbugs@HIDDEN>) id 1o1ije-0003L1-TK for 56002 <at> debbugs.gnu.org; Thu, 16 Jun 2022 02:12:09 -0400 Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-2ef5380669cso4186837b3.9 for <56002 <at> debbugs.gnu.org>; Wed, 15 Jun 2022 23:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GQIApe45Wocb7A6zQbPNlVOw3tDq2/Y1cR2BbbqBIzk=; b=LgDS++ZDuDL7eBr6mWZU07Z6KuY/CysPvePhstJ1MIFESSRW/9XDgnkH4mReNl91Fu YWTt+U2xhwRHYVWPILjO3WjIQ18IfmzLvFfCIQN0Ht1D5RM4RnwXkm30fmZAr471Vu/0 ZtJzYyYicNf63YyPi/dzo7KzOUbGVowfxmEtPxkokNihKxzrsYTIwkrQnnAYOe2OUOS8 cMaAd/OUo8/78veH/nq3Eu5dF/6QzWAS32AmphwoB2IG/tfim+QKBluLPrpDAzr3qYBt 8zdjofsBXjzFUwKrzyWRWXcSYyaa4zMDO8irdcBJOnwpKd9k1XZLGdmOYywzI0jyNtsB qTng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GQIApe45Wocb7A6zQbPNlVOw3tDq2/Y1cR2BbbqBIzk=; b=PBvyBafgTHvaUKTmuTmRuc+vhPW1q8UiYypmK17bqN+17lo+6raXyvLtBcTPWa7Oe3 UT1VRtTl1GKtWmWMbv1UvlPpcN4ZWRnm6QDDIwIrROh1iZ3KA6z7KGi9nsqaXb3lsYFi IlR5o6JyLj7PIsynvOzD7s3EOW2AfpiTsdXj6DbpR0lggB2/wTE5QsauXgroEJiBlmev yvpfeizwvzMJtZw7+Mzatg87oEZMAzp18cS7tEED1UYrcpCedLwnihPj3w1vXrkfvsG1 fxJ2j3P6PmUh24nEVshgEonltzZGDcFNaL91wcxdEOJJzPZkHN6x4gpN4pw++jC5r/Ug B4/g== X-Gm-Message-State: AJIora851jgrvnZC2k5SVye9Hcmr7VstnEKTDhkMJyTDDbxI8EXGPcgD VhfRi0uQT/RrH306owOeJk1s3JEueAX38qqUoluuDPlGyvQ= X-Google-Smtp-Source: AGRyM1uOwWni4kzS0ln4/0q0Covj/U8+8qxfUztHfbiC8UnY/aePe75Lo/RHDcP7wzqx+ciBsjHv9V/T2SYVrwbMvTg= X-Received: by 2002:a81:ed4:0:b0:2f1:c8db:ce23 with SMTP id 203-20020a810ed4000000b002f1c8dbce23mr3754919ywo.95.1655359921262; Wed, 15 Jun 2022 23:12:01 -0700 (PDT) MIME-Version: 1.0 References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN> <83pmj9qjgk.fsf@HIDDEN> In-Reply-To: <83pmj9qjgk.fsf@HIDDEN> From: Tom Gillespie <tgbugs@HIDDEN> Date: Wed, 15 Jun 2022 23:11:50 -0700 Message-ID: <CA+G3_PNnJ2akU9D2i3CGeYg=p56wzuy-gtzEGTk6kzmYrQyd6A@HIDDEN> Subject: Re: bug#56002: src/process.c; make-process fails to clean up stderr process on early exit To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56002 Cc: 56002 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Can you elaborate on what do you mean by "clean up the stderr > process"? Do you see the code which does that in the "normal" cases? I'm not entirely sure as I am unfamiliar with the life cycle for processes in the runtime. I think that the "normal" cleanup happens when the parent process exits with a return code. The stderr process is a pipe process so I assume that under normal circumstances the pipe process would receive a signal from the primary process via the os and exit allowing calls to accept-process-output to complete and then presumably the gc would take care of the rest? I have no idea if this is remotely accurate. It does look like remote_process is called during other failures though. > Sounds like we lack some unwind-protect call somewhere? It does look like there are a number of calls to record_unwind_protect (remove_process, proc); in the code. Maybe there is a missing record_unwind_protect (remove_process, stderrproc); in make-process?
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.
Received: (at 56002) by debbugs.gnu.org; 16 Jun 2022 05:13:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 16 01:13:48 2022
Received: from localhost ([127.0.0.1]:40424 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1o1hpD-0001kR-W9
for submit <at> debbugs.gnu.org; Thu, 16 Jun 2022 01:13:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41906)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1o1hpB-0001kB-2E
for 56002 <at> debbugs.gnu.org; Thu, 16 Jun 2022 01:13:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53626)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1o1hp5-0008Kj-P7; Thu, 16 Jun 2022 01:13:39 -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=Lqe9UaQXsrMypC8zWwn4572/wa2eFuOxk1c6vOrf0+8=; b=dmW1BZ2CXxZq
1tCHY5dNiOBh6FA/G8jDna5KOL4rZVpg+x5Q/psCM64sZCrEa9m/LHyEC9qMykjBcyeJWZO7JrG+O
1f4Q/c7kaS4myFfJIM8cx1bK8fQfW0S5rKr1Yr7OdcOBUo80P6B5bOIDAcmiAwqruXgspOPtr8n17
d7VcUwHdnjutEMzSoGydAnDck3TRNx6LDZFeHH75OLrNEmRq5M+NVCogR7LwBRS3+dzPLs4WWuwJw
GL+QXqjD+Sw6wmnUyd/WmD0zbcwSHsJgfC/IosqAppSdUPcPsiTgchs0irmtsmE1zjnJvZe1yzH2a
ISxz0s/61Ofw8rDZzNanMw==;
Received: from [87.69.77.57] (port=1839 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1o1hp4-0006nx-Sr; Thu, 16 Jun 2022 01:13:39 -0400
Date: Thu, 16 Jun 2022 08:13:31 +0300
Message-Id: <83pmj9qjgk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Tom Gillespie <tgbugs@HIDDEN>
In-Reply-To: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN>
(message from Tom Gillespie on Wed, 15 Jun 2022 15:38:05 -0700)
Subject: Re: bug#56002: src/process.c;
make-process fails to clean up stderr process on early exit
References: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 56002
Cc: 56002 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Tom Gillespie <tgbugs@HIDDEN>
> Date: Wed, 15 Jun 2022 15:38:05 -0700
>
> If the primary subprocess created by make-process fails early then the
> stderr process is not cleaned up and running kill-buffer on any stderr
> buffer attached to the stderr process will prompt the user.
Can you elaborate on what do you mean by "clean up the stderr
process"? Do you see the code which does that in the "normal" cases?
> Two early exits that can cause the issue are
>
> 1. in make-process if the command is not found
> report_file_error ("Searching for program", program);
>
> 2. in create_process if vfork fails
> report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, vfork_errno);
>
> I'm sure there are other failure modes that would trigger the issue.
Sounds like we lack some unwind-protect call somewhere?
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.
Received: (at 56002) by debbugs.gnu.org; 16 Jun 2022 02:28:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 15 22:28:41 2022
Received: from localhost ([127.0.0.1]:40213 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1o1fFR-0005e1-1Y
for submit <at> debbugs.gnu.org; Wed, 15 Jun 2022 22:28:41 -0400
Received: from mail-yw1-f176.google.com ([209.85.128.176]:44578)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <tgbugs@HIDDEN>) id 1o1fFO-0005do-0Y
for 56002 <at> debbugs.gnu.org; Wed, 15 Jun 2022 22:28:39 -0400
Received: by mail-yw1-f176.google.com with SMTP id
00721157ae682-3176b6ed923so959437b3.11
for <56002 <at> debbugs.gnu.org>; Wed, 15 Jun 2022 19:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:from:date:message-id:subject:to;
bh=JgrM2pPHF45F37BhnvfsdYa+QXf408TiPRZyu0yo6zU=;
b=icM5mBclhk9vnzEnXY9L76XXAkZPWPd4f/xjfo6Zq9dIC+0fXy6WDxB/N1ulQaDjvt
bSi1thfxAxnhXbkC0L+hksHgxITNuCVO9+LJIDqSjFltxwsdlDnqzu88Y0kag8y0qtpu
OPWMW4o08zK/fJ+xAsUJH/5mYNXZ9T7NTuSupccg3IirE/sA7CS46P4/0nKra/RyVYgo
rPsCUNx8Mu2ua6RQ9+Xm9u8IX2ToGC9BVd8PZiFWiK2/mB5ROFQLsrn1WMCWXemREplv
+KKY0hRH8oP/5HUTneIelCIRz4I7XhEvR3jJA9BQKdWdinK8W92Uhr2QCK3dINioNWpY
RdXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=JgrM2pPHF45F37BhnvfsdYa+QXf408TiPRZyu0yo6zU=;
b=7pGrqWXmELNf2BRg4FsdSIGkujqvfQSpzvHHB0sp4xokCBP9sT0BBv91/IAqiB5Zmy
uxMSIwmhA3ojFHxKEs+iIWuHLroPJrXKpY/bz29N0t+JnOiHMVfvb5i9NdiLB9Vu5+Mq
Zif0M5Ihvf1pBgUdhfJ0AuC+ZkkLJtulDsNtemo2s81EV0ktQgp8hNW3mHI3t+In5Ges
Kul2R07wJyY7tgEf7cybstxnpaV1oiQkOWwH12sGvoMzBg09HfvQZh7haeLVr8ho5QyJ
fu5+bXsv2GoqWsLGqDIVC2IV1NKRF3YGXJJCy05vTBEmCVn/aq9lg6XE6Kby86tcTcEv
V2ZQ==
X-Gm-Message-State: AJIora/gP+vTj1CPTdYUDZCpRMr/9sjiTb2I9hXrlJt7b6S3F46sy+y+
Yz4kBWcIm1GTbO5yotnM2B195SafzPPpIsKmY0yuwN8UV/o=
X-Google-Smtp-Source: AGRyM1saKzHY0mP80S9iUcQUzZI/YkbuR/V0q4AOOg3vEjqZTI4i0KKGMUYMtsH5ygN/YogudkW/EJnzKyZ0tHKDErY=
X-Received: by 2002:a81:ed4:0:b0:2f1:c8db:ce23 with SMTP id
203-20020a810ed4000000b002f1c8dbce23mr3107922ywo.95.1655346512262; Wed, 15
Jun 2022 19:28:32 -0700 (PDT)
MIME-Version: 1.0
From: Tom Gillespie <tgbugs@HIDDEN>
Date: Wed, 15 Jun 2022 19:28:21 -0700
Message-ID: <CA+G3_PM=Q--zhVj2Y_oqDmOiWnrpeCPHnwXc5VzMdphROKzLfw@HIDDEN>
Subject: update with an additional example
To: 56002 <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 56002
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
I have been reading the docs on accepting output again,
and I see that there might be some subtlety here, but in
fact following the examples in the docs should reveal
another way the bug can express itself.
Specifically, in the original example I did not call
accept-process-output on the stderr process as is
suggested by the docs. Unfortunately, the docs are
misleading in this case because I am doing things
inside an unwind-protect cleanup clause and
accepting output from the stderr process causes
the example (below) to hang forever.
I think this happens because the stderr process is not
cleaned up correctly, OR possibly because of some
unexpected interaction due to the use of unwind-protect.
Example:
#+begin_src bash
read -r -d '' example <<'EOF'
(let ((stderr-buffer (generate-new-buffer " rc stderr")))
(unwind-protect
(let ((process
(make-process
:name "process that never actually starts"
:stderr stderr-buffer
:command '("i_fail_before_there_can_be_a_return_code"))))
(message "this will never print because we never get here")
(while (accept-process-output process)))
(while (accept-process-output (get-buffer-process stderr-buffer)))
(kill-buffer stderr-buffer)))
EOF
emacs -Q -batch -eval "${example}"
#+end_src
Docs in question:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Accepting-Output.html
bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 15 Jun 2022 22:38:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 15 18:38:42 2022
Received: from localhost ([127.0.0.1]:40068 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1o1beq-00064t-0i
for submit <at> debbugs.gnu.org; Wed, 15 Jun 2022 18:38:42 -0400
Received: from lists.gnu.org ([209.51.188.17]:45682)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <tgbugs@HIDDEN>) id 1o1beZ-00064S-GJ
for submit <at> debbugs.gnu.org; Wed, 15 Jun 2022 18:38:38 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47674)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <tgbugs@HIDDEN>) id 1o1beZ-0003As-1h
for bug-gnu-emacs@HIDDEN; Wed, 15 Jun 2022 18:38:23 -0400
Received: from mail-yw1-x112b.google.com ([2607:f8b0:4864:20::112b]:35401)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <tgbugs@HIDDEN>) id 1o1beV-0006Qf-Vi
for bug-gnu-emacs@HIDDEN; Wed, 15 Jun 2022 18:38:22 -0400
Received: by mail-yw1-x112b.google.com with SMTP id
00721157ae682-31336535373so75670937b3.2
for <bug-gnu-emacs@HIDDEN>; Wed, 15 Jun 2022 15:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:from:date:message-id:subject:to;
bh=PnuR3Uk9Jd+MPo2eakgZ+JVK1fx1B1xlXN9L8g6bGa4=;
b=HoNp8wnIb6OsZbTUwcI7xoi5FQmLg93mN8vdgNPtWvOuEGQ7wQu2DF3dzttYYZQbqn
fS7DVpj0zvwnZ5xAnWebcJPl/XM1BX+5Y+sbn0iXHaJGkyLV5YuD3FodC3H8YEwnYeI0
Bn5B93c9ug3jvdANzU1w58/tc9Dc73ND5cjz0/gwqgxrRfBf6Iqb/Xb+Znkfgn+0nRcE
YQXV1aplnSA+lhEFZUb9GOqHhCWG+KDWzWshukmigO7foKvaVyQN7ajJ/1n9Gxz7PPfn
WI8OmL7QnGuE9DCFfpki7evJCVhDHPyA2gLcexP+Q3PU+tezKqRT5ftrc5AvH8Y9Xq1I
SBMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=PnuR3Uk9Jd+MPo2eakgZ+JVK1fx1B1xlXN9L8g6bGa4=;
b=0qnb1SSxE7A5f/T6AJ6gJY2AXwKBPk/o87l5iIC6nsnxFOe/wx7RKm7YZM/X8/v444
kqecjjrqTQ776D8MpcqiLGBJ8PxvUmx5nQ0B17sVI93HE6ZwwohTkiBQcoL4EaBGdr9S
hl4N85XZdHoaktE7FQNmByJyURW9hkSGeAJ3AnlUKZ6+FU36Xv78LCzE+I6F6OPV3G9U
NBm1pz8rhq2n+g7CeO/j7mMTRVer9tXAzZX2hmXCn3qo5R6XqrJF4iF5jR0q24AhiiY4
o3SQ2e2bocGAZz6AsT5NZODNlPHOsKJHY5Gw8CNR8M6CHeRkfDSsHMsM9E4caQOzsW8b
uGSw==
X-Gm-Message-State: AJIora/UVi7e0UgfaF5dj/fBYyryaX+N9ektXGisrBkdiUrUI4f2jy0c
aerh2UQxixAOTBKkQ50OfYhVflVUTFtmGVUOQFXwG9pkaiI=
X-Google-Smtp-Source: AGRyM1vjoSLFn3/M5DiVwedCZca8j2YsOxIiTVvhZ5IXc76JDHG/3/RPr1kPR2zM/fBxNfRvG0lXUU3wTUQPc5v88pE=
X-Received: by 2002:a0d:e691:0:b0:314:34e7:c562 with SMTP id
p139-20020a0de691000000b0031434e7c562mr2210317ywe.237.1655332695710; Wed, 15
Jun 2022 15:38:15 -0700 (PDT)
MIME-Version: 1.0
From: Tom Gillespie <tgbugs@HIDDEN>
Date: Wed, 15 Jun 2022 15:38:05 -0700
Message-ID: <CA+G3_PNbd+ENNcCRn-kD_kQhiTjhwqU4EKFCk=MN66gxfR_W=g@HIDDEN>
Subject: src/process.c;
make-process fails to clean up stderr process on early exit
To: Emacs Bug Report <bug-gnu-emacs@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::112b;
envelope-from=tgbugs@HIDDEN; helo=mail-yw1-x112b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
If the primary subprocess created by make-process fails early then the
stderr process is not cleaned up and running kill-buffer on any stderr
buffer attached to the stderr process will prompt the user.
Two early exits that can cause the issue are
1. in make-process if the command is not found
report_file_error ("Searching for program", program);
2. in create_process if vfork fails
report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, vfork_errno);
I'm sure there are other failure modes that would trigger the issue.
I know of at least two ways to trigger the behavior that correspond to
those two lines. One is to provide a :command that does not exist, the
other is to call an executable file with a format that Emacs does not
understand (e.g. a valid sh file that is missing a shebang line).
The following example shows the behavior for a non-existent command on
master at 556c304007fbea1a552c65529fa86c0a5637b27b. When running it
the program will stop at a prompt to kill the " rc stderr" buffer.
#+begin_src bash
read -r -d '' example <<'EOF'
(let ((stderr-buffer (generate-new-buffer " rc stderr")))
(unwind-protect
(let ((process
(make-process
:name "process that never actually starts"
:stderr stderr-buffer
:command '("i_fail_before_there_can_be_a_return_code")))))
(kill-buffer stderr-buffer)))
EOF
src/emacs -Q -batch -eval "${example}"
#+end_src
One potential fix for the issue would be to decouple :noquery for the
primary process from the stderr process and make the stderr process
query_on_exit always false. The user has no knowledge that the stderr
process exists and also has no way to reference it from their code. If
they want :noquery nil behavior an advanced user could always
construct the stderr process themselves.
If that is done then it seems that the stderr process will
automatically clean itself up once the stderr buffer is killed. This
seems easier than trying to catch all early exit cases that would
leave the stderr process alive during an early exit.
Tom Gillespie <tgbugs@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#56002; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.