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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 18 Jan 2025 20:57:01 +0200

> Date: Sat, 18 Jan 2025 17:31:57 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> >> 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.
> 
> 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?

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

> > The SIGUSR event is eventually entered into the keyboard buffer
> > anyway, so why should we treat it so differently from SIGIO?
> 
> Vdebug_on_event isn't, AFAICS.  Not a major change to make it so,
> though.  I don't know why we eat this event, but we do.

I guess because we want the debugger to pop up before any queued
events are processed.  But I don't see why doing the same in
gobble_input should produce different behavior.