bug#56002: src/process.c; make-process fails to clean up stderr process on early exit

[Eli Zaretskii <eliz@gnu.org>]

> From: Tom Gillespie <tgbugs@gmail.com>
> 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?