GNU bug report logs - #79014
31.0.50; igc: infinite loop

Previous Next

Full log

Message #32 received at 79014 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Óscar Fuentes <oscarfv <at> eclipso.eu>
Cc: "Óscar Fuentes via Bug reports for GNU Emacs, the Swiss
 army knife of text editors" <bug-gnu-emacs <at> gnu.org>, 79014 <at> debbugs.gnu.org
Subject: Re: bug#79014: 31.0.50; igc: infinite loop
Date: Mon, 14 Jul 2025 17:03:49 +0200

Óscar Fuentes <oscarfv <at> eclipso.eu> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Thanks. That's a recursive call to igc_on_idle from Lisp being called
>> whle it is running. Looks like something like this is needed:
>
> Thanks Gerd. Looks like the backtrace was useful after all :-)

:-)

>
> As I implied on my previous message, it would be useful to understand in
> what circunstances a recursive call to igc_on_idle happens. More
> precisely, why Emacs enters an idle state within an idle state. And how
> the time used by igc_on_idle is accounted for idle timers.
>
> Those are general questions, not addressed at you specifically.

It's difficult.

igc_on_indle is called when timer_check runs. That function basically
let's Lisp timers work as one would expect, and that is done, because
everything is synchronous, by calling timer_check at points where
someone though we have the time to do it.

One point is when reading input events and another is somewhere in
wait_reading_process_input. And it happens that in your case somewhere
in the Ffuncall that was on the backtrace one of the points was hit.

IOW, in this case, timer_check was also called recursively. But since
that can apparently happen independent of igc, I've left it alone of
course.

Maybe also igc_on_idle is not a good name. Don't know.

My 2 cents. Maybe someone else can say more, or has an idea how to do it
better. 

Previous Next

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