[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56002: src/process.c; make-process fails to clean up stderr process
From: |
Eli Zaretskii |
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 |
> 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?
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Tom Gillespie, 2022/08/07
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Lars Ingebrigtsen, 2022/08/08
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Eli Zaretskii, 2022/08/08
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Tom Gillespie, 2022/08/08
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Eli Zaretskii, 2022/08/09
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Tom Gillespie, 2022/08/09
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit,
Eli Zaretskii <=
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Tom Gillespie, 2022/08/10
- bug#56002: src/process.c; make-process fails to clean up stderr process on early exit, Eli Zaretskii, 2022/08/11