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


View this message in rfc822 format

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: bug#75632: 31.0.50; igc: Crash report
Date: Sat, 18 Jan 2025 22:18:16 +0200
> Date: Sat, 18 Jan 2025 19:53:50 +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:
> 
> >> So (!initialized) it is?  That works for temacs and emacs (I originally
> >> thought it would be wasteful for non-interactive temacs, but I'm sure
> >> someone's using that :-) ).
> >
> > As long as we understand well what it means to free in emacs a string
> > that was xstrdup'ed in temacs, yes.  Suppose debug-on-event is changed
> > in emacs to something else, how would xfree work in that case?
> 
> pdumper doesn't work that way (unexec did, I think): a static variable
> that isn't "remembered" by pdumper isn't saved, and it starts out as
> NULL in the dumped Emacs, and is replaced by the new xstrdup.  The old
> xstrdup (and the memory it allocated) are gone after the dump.

But if we use !initialized, the code which installs the variable
watcher will not run in the dumped Emacs, right?

> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag
> >> directly (or use QUITP); we wouldn't be able to break out of one of
> >> those if we only set Vinhibit_quit from what's currently
> >> store_user_signal_events, would we?
> >
> > Sorry, I don't follow.  Why does it matter whether we set those
> > variables from a signal handler or in gobble_input?
> 
> We might never reach gobble_input if the variable isn't set in the
> signal handler: some loops check QUITP (etc.), and if there's a bug in
> them and Vinhibit_quit is set, the loop might never call maybe_quit.

Then how about setting Vquit_flag and resetting Vinhibit_quit in the
handler, but leaving the check whether we should call the debugger to
gobble_input?




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.