[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58956: mark_object, mark_objects(?) crash
From: |
Vincent Lefevre |
Subject: |
bug#58956: mark_object, mark_objects(?) crash |
Date: |
Thu, 3 Nov 2022 11:13:08 +0100 |
User-agent: |
Mutt/2.2.7+51 (a318ca5a) vl-149028 (2022-10-21) |
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 <vincent@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)
- 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 <=
- 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, 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, Paul Eggert, 2022/11/06
- bug#58956: mark_object, mark_objects(?) crash, Eli Zaretskii, 2022/11/06