bug#58956: mark_object, mark_objects(?) crash

[Eli Zaretskii]

> Date: Sun, 6 Nov 2022 11:18:03 -0800
> Cc: akrl@sdf.org, vincent@vinc17.net, spwhitton@spwhitton.name,
>  58956@debbugs.gnu.org, 1017711@bugs.debian.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2022-11-05 22:51, Eli Zaretskii wrote:
> 
> > 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?
> 
> It depends on the OS and the app that invokes Emacs and how that app 
> itself was invoked. It's a hairy area.
> 
> On a POSIX platform it's certainly *possible* for Emacs to get SIGHUP in 
> that situation, because a user can invoke the shell command 'kill -s HUP 
> P', where P is the process ID of the inferior Emacs. Whether it's 
> *likely* is a bit harder to say. I ran a few little experiments on 
> Fedora 36 and Ubuntu 22.10 and found SIGHUP being sent in a few 
> situations and not others and didn't have the time or patience to suss 
> out exactly why or when.

Thanks.  The scenario that is of primary interest in this case is the
following:

 . user starts Emacs
 . Emacs loads some Lisp package and as results starts a subordinate
   Emacs process in batch mode to native-compile the loaded Lisp
 . user exits Emacs

My question was whether in this scenario, since the parent Emacs
exits, the child Emacs can get SIGHUP, simply because its parent
exited and the read end of the PTY no longer exists.