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: Mon, 8 Aug 2022 11:54:09 -0700
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 56002@debbugs.gnu.org
> 
> > TBH, I don't understand the rationale well enough.  What does it mean
> > we "leak stderr process"? isn't the stderr process recycled if
> > make-process fails?
> 
> When the stderrproc is created internally there is no way that it can be
> reused because nothing else has a reference to it. The changes here only
> deal with cases where a stderrproc is not provided by the caller.

This is a misunderstanding: I meant "recycled" as in
"garbage-collected".  GC in Emacs is supposed to prevent leaks of
memory and resources.  You seem to be saying that this somehow doesn't
work in this case.  Can you explain why it doesn't work, and which
resources specifically appear to be leaking?

> > Is it just a matter of some simple change in the
> > control flow, to make sure we always go through the cleanup code
> > before we return?
> 
> There is no way easy way to modify the control flow because there are
> so many possible points where process creation can fail unexpectedly
> that must be handled if the stderrproc is created too early.

But we have code that errors out in the middle of processing all over
the place, and that is safe in Emacs, because any unused Lisp objects
will be GC'ed soon.  Why is this case special?

> It is very hard to determine exactly which statements inside of make
> process can produce unexpected exits, I have encountered at least
> two, but I'm sure there are others. Thus the safest thing to do was to
> move creation of stderrproc after all the points where process creation
> can potentially fail (e.g. failures during vfork).
> 
> > In general, I'd prefer not to change timing of what we do in
> > make-process unless it's really unavoidable.  There's a lot of
> > system-dependent stuff there, and who knows what will that cause on
> > some platform?
> 
> I'm fairly certain that it is impossible for there to be any interaction between
> the primary process and the stderr proc at any point in time prior to where
> I moved the creation of the stderrproc because the first reference to
> p->stderrproc after it is created is in create_process.

I meant the potential interactions that are not explicitly visible by
reading the code, but instead stem from system-dependent stuff that is
related to how subprocesses are created on different systems.

So I'd still be happier if we could deal with the problem without
moving chunks of code around.

Thanks.