GNU bug report logs - #75632
31.0.50; igc: Crash report

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Fri, 17 Jan 2025 14:35:02 UTC

Severity: normal

Found in version 31.0.50

Done: Pip Cet <pipcet <at> protonmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 75632 <at> debbugs.gnu.org
Subject: Re: bug#75632: 31.0.50; igc: Crash report
Date: Sat, 18 Jan 2025 11:42:44 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Fri, 17 Jan 2025 21:30:41 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: 75632 <at> debbugs.gnu.org, yantar92 <at> posteo.net
>>
>> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>>
>> >> I'm not sure what you are suggesting here.  Is there a good place that
>> >> is initialized only in the !pdumper || !temacs case?
>> >
>> > The "if (initialized)" test is exactly for that.  pdumper_load sets
>> > initialized = true before it returns.  So in temacs initialized will
>> > be false when init_keyboard is called.
>>
>> But if we build without pdumper (after removing the relevant #error and
>> a few minor fixes, it works just fine), initialized is false, so SIGUSR2
>> wouldn't work at all in those builds.
>
> Do we want to support MPS in unexec builds?  I thought we didn't.
> (Does it even work in such builds?)

I was talking about --with-dumping=none, not unexec builds.  I"m not
fixing unexec bugs!

>> In the pdumper case, it'd run in temacs, put the right subr in the
>> symbol's plist, dump it, and then it'd be restored from the dump and
>> we'd only need the initial call.
>>
>> Would that be okay?
>
> I have no idea, because I don't understand why is that the solution to
> SIGUSR handling.  (How about adding some comments which explain the
> purpose of watching that variable?)  Also see above regarding unexec
> build with MPS.

Vdebug_on_event points to data behind a memory barrier.  It's replaced
by a C string which is xstrdup'd, so that's not behind a memory barrier.
keeping the two in sync is done with a variable watcher, as is the case
for gc-cons-threshold.

Variable watchers survive dump/reload cycles, so we set it up just once,
when !initialized; when entering the code in the post-dump state, we
perform the initial dummy "watch" event to initialize the C string.

Pip





This bug report was last modified 115 days ago.

Previous Next


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