GNU bug report logs - #58956
mark_object, mark_objects(?) crash

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 58956 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name, vincent <at> vinc17.net, 1017711 <at> bugs.debian.org, akrl <at> sdf.org
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 <at> vinc17.net, spwhitton <at> spwhitton.name, 58956 <at> debbugs.gnu.org,
>  1017711 <at> bugs.debian.org
> From: Paul Eggert <eggert <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.