[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58956: mark_object, mark_objects(?) crash
From: |
Eli Zaretskii |
Subject: |
bug#58956: mark_object, mark_objects(?) crash |
Date: |
Sun, 06 Nov 2022 07:51:18 +0200 |
> Date: Sat, 5 Nov 2022 13:54:54 -0700
> Cc: vincent@vinc17.net, spwhitton@spwhitton.name, 58956@debbugs.gnu.org,
> 1017711@bugs.debian.org
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> On 2022-11-04 00:00, Eli Zaretskii wrote:
> > We need to establish what is the
> > source of SIGHUP in these cases. "These cases" mean, AFAIU, the
> > situations where Emacs launched an async subprocess to do native
> > compilation (which is another Emacs process in a --batch session), and
> > the parent Emacs session is terminated by the user before the async
> > compilation runs to completion. Would the child Emacs process get
> > SIGHUP in this scenario?
>
> Hard for me to say. It's a messy area, with kernels (and Emacs itself)
> sending SIGHUP on various whims.
But is it possible for a program like Emacs to get SIGHUP in such a
situation, or is that highly improbable? We have standard streams of
the inferior Emacs process connected via PTYs to the parent process, I
believe -- does that deliver SIGHUP or SIGPIPE when the parent exits?
> Does the attached patch fix things? It builds on your commit
> 190a6853708ab22072437f6ebd93beb3ec1a9ce6 dated 2020-12-04; I don't know
> why that earlier patch was installed, but it would seem to apply to
> SIGHUP and SIGTERM as well as it applies to SIGINT.
I was trying to be conservative, that's all. I'm okay with doing the
same for SIGHUP. Vincent, can you try this patch, please?
- bug#58956: mark_object, mark_objects(?) crash, Sean Whitton, 2022/11/01
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/02
- bug#58956: mark_object, mark_objects(?) crash, Vincent Lefevre, 2022/11/02
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/03
- bug#58956: mark_object, mark_objects(?) crash, Vincent Lefevre, 2022/11/03
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/03
- bug#58956: mark_object, mark_objects(?) crash, Andrea Corallo, 2022/11/03
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/04
- bug#58956: mark_object, mark_objects(?) crash, Andrea Corallo, 2022/11/04
- bug#58956: mark_object, mark_objects(?) crash, Paul Eggert, 2022/11/05
- bug#58956: mark_object, mark_objects(?) crash,
Eli Zaretskii <=
- bug#58956: mark_object, mark_objects(?) crash, Paul Eggert, 2022/11/06
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/06
- bug#58956: mark_object, mark_objects(?) crash, Paul Eggert, 2022/11/06
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/06
- bug#58956: mark_object, mark_objects(?) crash, Sean Whitton, 2022/11/08
- bug#58956: mark_object, mark_objects(?) crash, Vincent Lefevre, 2022/11/10
- bug#58956: mark_object, mark_objects(?) crash, Sean Whitton, 2022/11/11
- bug#58956: mark_object, mark_objects(?) crash, Vincent Lefevre, 2022/11/11
- bug#58956: mark_object, mark_objects(?) crash, Sean Whitton, 2022/11/14
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/10