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

Previous Next

Full log

View this message in rfc822 format

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: bug#75632: 31.0.50; igc: Crash report
Date: Sat, 18 Jan 2025 20:40:47 +0000

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

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

Correct.  Variable watchers are symbol properties, and symbol properties
are restored from the dump, so there is no need to add them again.

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

1. We can't do that unconditionally.  An ordinary SIGUSR2 should not
cause a quit, only a special event should.  So we need to check whether
the event we received is special or not.

2. probably_quit handles the quit flag first, then handles pending
signals only when it is called again, by the next maybe_quit.  That
means by the time we reach gobble_input, it's too late to call the
debugger.  So we need to set debug_* at the same time as setting
Vquit_flag (or rewrite probably_quit, which probably has very good
reasons for its peculiar behavior).

Pip

Previous Next

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