Freezing frame with igc

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

(Subject changed.)

Pip Cet <pipcet@protonmail.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>>> Redisplay just stopped while showing the menu, no crash nor infinite
>>>> loop, its CPU usage was typical for the repeating timers that my config
>>>> creates.
>>>
>>> That's a bit odd.  It might be the signal issue, but that's purely a
>>> guess.  If it happens again, please let us know.
>>
>> Sure.
>
> I'm not a hundred percent sure, because I was testing other changes, but
> I just observed an Emacs session in a very similar state to what you
> describe: very little but nonzero CPU usage, but unresponsive to X
> interactions.  I attached gdb, observed it was stuck in read_char, then
> I messed up and set Vquit_flag to Qt, at which point the Emacs session
> recovered and seems fully usable once more (it did take a while to do
> so, though).  So no valuable debug info this time, hope I'll hit it
> again.
>
> Again, it's possible this is a similar-looking but different bug,
> possibly caused by local changes.
>
> I don't think read_char or its subroutines even use MPS memory, though?
> As this is a GTK build, and yours wasn't, we should probably look at X
> interaction code shared between the GTK and non-GTK builds.
>
> Pip

That reminds of something. Maybe what you've seen is completely
unrelated, it's impossible to tell, but please find below a comment that
I added to do_switch_frame in frame.c.

  /* We want to make sure that the next event generates a frame-switch
     event to the appropriate frame.  This seems kludgy to me, but
     before you take it out, make sure that evaluating something like
     (select-window (frame-root-window (make-frame))) doesn't end up
     with your typing being interpreted in the new frame instead of
     the one you're actually typing in.  */

  /* FIXME/tty: I don't understand this.  (The comment above is from
     Jim BLandy 1993 BTW, and the frame_ancestor_p from 2017.)

     Setting the last event frame to nil leads to switch-frame events
     being generated even if they normally wouldn't be because the frame
     in question equals selected-frame.  See the places in keyboard.c
     where make_lispy_switch_frame is called.

     This leads to problems at least on ttys.

     Imagine that we have functions in post-command-hook that use
     select-frame in some way (e.g., with-selected-window).  Let these
     functions select different frames during the execution of
     post-command-hook in command_loop_1.  Setting
     internal_last_event_frame to nil here makes these select-frame
     calls (potentially and in reality) generate switch-frame events.
     (But only in one direction (frame_ancestor_p), which I also don't
     understand).

     These switch-frame events form an endless loop in
     command_loop_1.  It runs post-command-hook, which generates
     switch-frame events, which command_loop_1 finds (bound to '#ignore)
     and executes, which again runs post-command-hook etc., ad
     infinitum.

     Let's not do that for now on ttys.  */