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

[ISHIKAWA,chiaki]

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 file I was editing is a Japanese text file.  Sorry, it contains 
proprietary information and I can't share it immediately.  However, I
will be editing it again with emacs this afternoon and if the problem 
recurs, I will try to redact it as much as possible and see if the
runaway problem recurs then.

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?

TIA.

Regars,
Chiaki

One stacktrace with bidi_cache_searh at the top.
I notice that charpos 358 was near the end of the file (probably at the 
end?) when I had to kill the emacs..
Sorry I had to recover the edited file after killing emacs, and it may 
no longer contain the exact buffer data when the problem occurred.

thread 1 "emacs" received signal SIGINT, Interrupt.
0x0000556f1905af04 in bidi_cache_search (charpos=charpos@entry=358,
    dir=dir@entry=1, level=-1) at bidi.c:660
660          if (charpos < bidi_cache[bidi_cache_last_idx].charpos)
(gdb) where
#0  0x0000556f1905af04 in bidi_cache_search
    (charpos=charpos@entry=358, dir=dir@entry=1, level=-1) at bidi.c:660
#1  0x0000556f1905b8a9 in bidi_cache_find
    (charpos=358, resolved_only=resolved_only@entry=false, 
bidi_it=bidi_it@entry=0x7ffeb7caae48) at bidi.c:877
#2  0x0000556f1905db97 in bidi_resolve_brackets
    (bidi_it=bidi_it@entry=0x7ffeb7caae48) at bidi.c:2883
#3  0x0000556f1905df79 in bidi_resolve_neutral
    (bidi_it=bidi_it@entry=0x7ffeb7caae48) at bidi.c:3010
#4  0x0000556f1905e4a1 in bidi_type_of_next_char (bidi_it=0x7ffeb7caae48)
    at bidi.c:3215
#5  bidi_level_of_next_char (bidi_it=bidi_it@entry=0x7ffeb7caae48)
    at bidi.c:3282
#6  0x0000556f1905f60e in bidi_move_to_visually_next
    (bidi_it=bidi_it@entry=0x7ffeb7caae48) at bidi.c:3485
#7  0x0000556f18fe0d7a in set_iterator_to_next
    (it=0x7ffeb7caa410, reseat_p=<optimized out>) at xdisp.c:8588
#8  0x0000556f18fdcb8d in move_it_in_display_line_to
    (it=it@entry=0x7ffeb7caa410, to_charpos=to_charpos@entry=2078, 
to_x=to_x@entry=-1, op=op@entry=MOVE_TO_POS) at xdisp.c:10268
#9  0x0000556f18fe1b88 in move_it_to
    (it=it@entry=0x7ffeb7caa410, to_charpos=2078, to_x=to_x@entry=-1, 
to_y=to_y@entry=-1, to_vpos=to_vpos@entry=-1, op=op@entry=8) at 
xdisp.c:10623
#10 0x0000556f18fe358c in resize_mini_window (w=0x556f1a3b4240, 
exact_p=true)
    at xdisp.c:12778
#11 0x0000556f18fc973a in with_echo_area_buffer
    (w=0x556f1a3b4240, which=which@entry=0, fn=fn@entry=0x556f18fe4250 
<resize_mini_window_1>, a1=0x556f1a3b4240, a2=0x30) at xdisp.c:12422
#12 0x0000556f18ff5269 in resize_echo_area_exactly () at xdisp.c:12678
#13 0x0000556f190de46d in command_loop_1 () at keyboard.c:1528
#14 0x0000556f19156377 in internal_condition_case
    (bfun=bfun@entry=0x556f190ddcb0 <command_loop_1>, 
handlers=handlers@entry=0x90, hfun=hfun@entry=0x556f190d0f40 
<cmd_error>) at eval.c:1474
#15 0x0000556f190c9bf6 in command_loop_2 (handlers=handlers@entry=0x90)
    at keyboard.c:1133
#16 0x0000556f191562d1 in internal_catch
    (tag=tag@entry=0x10080, func=func@entry=0x556f190c9bd0 
<command_loop_2>, arg=arg@entry=0x90) at eval.c:1197
#17 0x0000556f190c9b91 in command_loop () at keyboard.c:1111
#18 0x0000556f190d0af1 in recursive_edit_1 () at keyboard.c:720
#19 0x0000556f190d0e70 in Frecursive_edit () at keyboard.c:803
#20 0x0000556f18fa3cf2 in main (argc=7, argv=0x7ffeb7cabd08) at emacs.c:2529
(gdb) c