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

Previous Next

Full log

Message #26 received at 58956 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58956 <at> debbugs.gnu.org, Vincent Lefevre <vincent <at> vinc17.net>,
 1017711 <at> bugs.debian.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58956: mark_object, mark_objects(?) crash
Date: Thu, 03 Nov 2022 21:25:08 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 3 Nov 2022 11:13:08 +0100
>> From: Vincent Lefevre <vincent <at> vinc17.net>
>> Cc: spwhitton <at> spwhitton.name, 58956 <at> debbugs.gnu.org,
>> 	1017711 <at> bugs.debian.org
>> 
>> 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".
>
> Andrea, could you please look into this?  The SIGHUP could be because
> the parent process exits, but that shouldn't cause a crash in the
> sub-process that performs native compilation?

Hi Eli,

AFAIU the Emacs subprocess we use to compile should behave like a
regular Emacs.

Now, the only option that comes to my mind is that libgccjit (being
strictly derived from the GCC codebase) might be registering a signal
handler of some kind that alters the behaviour we expect.  But if this
is the case we should find trace of it the strace, or we can use gdb
setting a break point into 'signal' as well to check.

Indeed if this theory is true I think should be classified as a
libgccjit bug.

  Andrea

Previous Next

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