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

Previous Next

Full log

Message #43 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 14:27:03 +0000

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

>> Date: Sat, 18 Jan 2025 11:42:44 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: 75632 <at> debbugs.gnu.org, yantar92 <at> posteo.net
>>
>> >> 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!
>
> OK, so the only interesting use case is running temacs when not
> dumping it.

I think it's important to keep temacs/emacs without dumping runnable.
It's certainly still interesting when temacs is called emacs.

>> >> 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.
>
> OK, but what does this have to do with SIGUSR handling?

The SIGUSR* handler needs to access that string.  Signal handlers cannot
access MPS-managed memory, so we need to put the string in regular
xmalloc memory.

I think that's clear from the commit message, by the way.  If it isn't,
I'd appreciate advice on how to improve it.  (Maybe it's a good idea to
use the extended ChangeLog format with an explanatory paragraph between
the header line (which some git utilities insist on keeping shorter than
it should be) and the individual files' changes.)

Pip

Previous Next

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