bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off?

[Eli Zaretskii]

> Cc: "ishikawa, chiaki" <ishikawa@yk.rim.or.jp>
> Date: Tue, 19 Sep 2023 13:12:33 +0900
> From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
> 
> High CPU usage, basically runaway emacs with visit to bidi_cache_search 
> on and off?
> 
> Hi,
> 
> Environment:
> OS GNU/Debian Linux  X86_64
> Emacs version
> GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
> cairo version 1.16.0) of 2023-08-01
> I compiled emacs using gcc.
> 
> Has anyone seen emacs 29.1 spending CPU way too high, basically went
> into an infinite loop of some sort, and could not be interrupted by
> Control-G?  Basically it is in a runaway state.
> I found that the stacktraces show that bidi_cache_search
> and friends are visited now and then.  It is not the recursive blowup 
> probably since the stack depth is quite limited during my observation.
> 
> 
> I have experienced this issue this morning.  Observing the stack
> backtrace by monitoring the runaway emacs using gdb, I was surprised
> to see many appearances of bidi_cache_search that were observed from
> time to time while I do control-C to stop emacs and monitor
> stacktrace, and the continue for a few seconds, and interrupt it again
> with control-C.  After letting emacs run in this manner for about 5
> minutes, I had tp kill emacs.  I had to edit the file by a deadline and 
> could not continue debugging. :-(
> 
> At the end is a single stacktrace with bidi_cache_search at the top.
> I have seen this occurring multiple times. My hitting control-C to emacs 
> to enter gdb interaction means that the chance of hitting a particular 
> stacktrace pattern is small and seeing the same pattern multiple times 
> means that that pattern happens quite often.

The backtrace shows we were resizing the mini-window, but it doesn't
tell where and why we were looping.

(The bidi_cache_search part is probably a red herring: that function
is indeed called very frequently when Emacs performs display and
layout calculations -- which is not surprising, since that's why the
bidi cache exists: to provide cache hits whenever possible.)

So it is important to have a file and the sequence of commands that
trigger this.  Please try to produce such a file and a recipe to
reproduce the problem.

Alternatively, you can use the technique described in etc/DEBUG for
finding where Emacs loops, see there under "If the symptom of the bug
is that Emacs fails to respond".  I think even if you do discover
where it loops, we'd need an example file to see why, though.

> I have a dozen or so more different stacktraces during gdb monitoring.
> If someone wants to see the log, I can post it.
> What is the preferred URL where I can paste the whole gdb session?

You can post them here, perhaps compressed.  However, if they are all
of the same kind, i.e. start with resize_echo_area_exactly, then I
don't think more backtraces alone will help.

Thanks.