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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
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 17:50:16 +0200

> Date: Sat, 18 Jan 2025 14:27:03 +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 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.

Yes, of course, no argument here.

> >> 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.

So this is just to allow the signal handler access to the event name?

I'd be much happier if we instead treated this as we treat SIGIO that
is delivered when the user presses a keyboard key: set a flag saying
that input is available, and then process it as we do with keyboard.
The SIGUSR event is eventually entered into the keyboard buffer
anyway, so why should we treat it so differently from SIGIO?

> 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.

These details are better said in comments to the code than in commit
log messages.  Looking for explanations for what the code does in Git
history is less convenient, and I'm quite sure some people will not
even think about it, at least not at first.

Previous Next

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