Subject: Re: bug#75632: 31.0.50; igc: Crash report

From: Eli Zaretskii <[email-masked]>
Date: Sat, 18 Jan 2025 22:18:16 +0200

> Date: Sat, 18 Jan 2025 19:53:50 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> 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?