On 2022-11-03 08:47:06 +0200, Eli Zaretskii wrote: > > On 2022-11-02 14:24:51 +0200, Eli Zaretskii wrote: > > > Signal 1 is SIGHUP, AFAIU. Why should Emacs receive SIGHUP in the > > > middle of GC, I have no idea. Maybe ask the user what was he doing at > > > that time. E.g., could that be a remote Emacs session? > > > > No, it is on my local machine. > > So how come Emacs gets a SIGHUP? This is the crucial detail that is > missing here. Basically, if SIGHUP is delivered to Emacs, Emacs is > supposed to die a violent death.
I suspect the SIGHUP comes from Emacs itself. According to strace output, the only processes started by Emacs are "/usr/bin/emacs" (there are many of them). I don't see what other process could be aware of the situation. Unfortunately, I couldn't reproduce the issue with strace (I suspect some race condition). > > I run emacs, and quit it immediately. The generation of the core dump > > is almost 100% reproducible. Ditto with "emacs -nw". > > Wait, you mean the crash is during exiting Emacs? For this test, yes. In general, I don't know. > That could mean Emacs receives some input event when it's half-way > through the shutdown process, and the input descriptor is already > closed. Note that the process that crashes is not the Emacs I started, but a subprocess run by Emacs itself, since it has arguments like "-no-comp-spawn --batch -l /tmp/emacs-async-comp-url.el-FGov4z.el". However, it also happened that the Emacs I started immediately crashed (this occurred only once, though). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
