Subject: bug#79014: 31.0.50; igc: infinite loop

From: Óscar Fuentes <[email-masked]>
Date: Mon, 14 Jul 2025 16:27:25 +0200

Eli Zaretskii <[email-masked]> writes:

>> > Any idea what it was trying to warn about in display-warning frames?
>> 
>> No, sorry.
>> 
>> > I suspect it's some kind of memory-full situation.
>> 
>> I'll mention this in case it is relevant: Emacs was using about 2.8 GB
>> of RSS and that machine has 64 GB of RAM, almost all free.
>> 
>> > Do you still have that session in GDB?
>> 
>> No :-(
>
> Then I don't see how we could do anything with this report.  Too bad.
> Please in the future try to leave the crashed session inside GDB at
> least for a while.

That's a remote machine that runs Emacs as a daemon. Probably I could
figure out how to run another remote instance without killing the
previous one, but I had urgent work to do.

> Unless someone has ideas how to make some progress with this bug, I
> will soon close it as unreproducible.

Let's see what Pip has to say.

I think I have seen a similar backtrace on the past. The sequence of
nested calls doesn't look too sane (timer_check ... igc_on_idle ...
truncate_undo_list ... display_warning ... Finput_pending_p ...
timer_check) but as mini-echo-mode [1] was active, it starts making
sense.

mini-echo hides the modeline and uses a repeating idle timer for
updating the echo area with the information that usually would be in the
modeline. That can execute arbitrary code.

Bug 74547 was also a crash with the igc/mini-echo combo. Looks like if
the mini-echo timer does its thing at the "wrong" moment wrt igc state,
problems arise.

For starters, does it make sense for igc_on_idle to be recursive?
Can't that function detect that is being called recursively and just
return?

Another thought: does the time consumed by igc_on_idle count as idle
time for idle timers?

1 https://github.com/eki3z/mini-echo.el