GNU logs - #66096, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off?
Resent-From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Sep 2023 04:13:01 +0000
Resent-Message-ID: <handler.66096.B.169509674229413 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 66096 <at> debbugs.gnu.org
Cc: "ishikawa, chiaki" <ishikawa@HIDDEN>
Message-ID: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
Date: Tue, 19 Sep 2023 13:12:33 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=219.118.72.101;
 envelope-from=ishikawa@HIDDEN; helo=mail01.SiriusCloud.jp
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Subject: bug#66096: Acknowledgement (High CPU usage, basically runaway
 emacs with visit to bidi_cache_search on and off?)
Message-ID: <handler.66096.B.169509674229413.ack <at> debbugs.gnu.org>
References: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
X-Gnu-PR-Message: ack 66096
X-Gnu-PR-Package: emacs
Reply-To: 66096 <at> debbugs.gnu.org
Date: Tue, 19 Sep 2023 04:13:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 66096 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
66096: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66096
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off?
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Sep 2023 11:05:01 +0000
Resent-Message-ID: <handler.66096.B66096.1695121469517 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Cc: 66096 <at> debbugs.gnu.org, ishikawa@HIDDEN
Date: Tue, 19 Sep 2023 14:04:08 +0300
Message-Id: <834jjqe85z.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
 (ishikawa@HIDDEN)
References: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Cc: "ishikawa, chiaki" <ishikawa@HIDDEN>
> Date: Tue, 19 Sep 2023 13:12:33 +0900
> From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
> 
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off?
Resent-From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Sep 2023 07:09:02 +0000
Resent-Message-ID: <handler.66096.B66096.16951937149454 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 66096 <at> debbugs.gnu.org, "ishikawa, chiaki" <ishikawa@HIDDEN>
Content-Type: multipart/mixed; boundary="------------kcjWW2kzp4JrMOBLWEZZB3WC"
Message-ID: <80682fbe-b5ac-4605-b8e5-7baac2d71da5@HIDDEN>
Date: Wed, 20 Sep 2023 16:09:03 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
 <834jjqe85z.fsf@HIDDEN>
Content-Language: en-US
From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
In-Reply-To: <834jjqe85z.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is a multi-part message in MIME format.
--------------kcjWW2kzp4JrMOBLWEZZB3WC
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2023/09/19 20:04, Eli Zaretskii wrote:
>> Cc: "ishikawa, chiaki" <ishikawa@HIDDEN>
>> Date: Tue, 19 Sep 2023 13:12:33 +0900
>> From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
>>
>> 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.
>
Thank you for your comment.

There seem to be enough variation of the stacktrace patterns.

I am attaching the gdb session file as zipped archive.
As you suggested, it seems Emacs is trying to resize echo area, and is 
looping somehow.
resize_echo_area_exactly () seems to be always there.
It could be that it was trying to dump the S-expression that encodes the 
latest GC information after each GC.

I have the following code snippet to monitor GC issues on my PC for 
quite sometime.
But I have not seen this particular problem before.
The long pause I have seen before was strictly in GC-related routines.

(setq my-gc-statistics (make-vector 30 nil))

;;; The element is
;;; (append (memory-use-counts) (list gc-elapsed gcs-done))
;;; Each time the following function is called, the
;;; elements in the array is shifted toward the end.
;;; Use (message "%S" my-gc-statistics) to force the
;;; recording of my-gc-statistics value in *Messages* buffer for later 
analysis.


(defun update-my-gc-statistics ()
   (let ((i 28))
     (progn
      ;;; very unlike Lisp
      (while (<= 0 i)
        (progn (aset my-gc-statistics (+ 1 i) (aref my-gc-statistics i))
              (setq i (- i 1) )))
      (aset my-gc-statistics 0
            (append (memory-use-counts) (list gc-elapsed gcs-done)))
      ;;; print the latest one last so that I can see the glimpse in the 
narrow
      ;;; output window.
      (message "%S\n%S" (current-time-string) (pp (reverse 
my-gc-statistics))))))

(setq post-gc-hook 'update-my-gc-statistics)

For example, in one place, I see
#0  0x0000556f1905be9e in string_char_and_length
     (length=<synthetic pointer>, p=0x556f20d8a3d8 " 70337 417360 
2.323839139 50)\n (99058573 3875 59193441 34949 11084445 70337 417401 
2.391973008 51)]\n\"") at 
/home/ishikawa/repos/emacs-29.1/src/character.h:375

And that string is probably   from (append (memory-use-counts) (list 
gc-elapsed gcs-done))

Also I see recursive_edit at the bottom of the stakctrace.
Not sure why. Maybe I was doing some error recovery of Japanese input?


In any case, Emacs should not enter a state that cannot be interrupted 
by CONTROL-G for a long time IMHO.
(Or was it that the processing of control-G somehow resulted in the 
effort to widen echo area and emacs failed?)

TIA


Chiaki

--------------kcjWW2kzp4JrMOBLWEZZB3WC
Content-Type: application/x-zip-compressed;
 name="emacs-cant-be-interrupted-with-control-g.zip"
Content-Disposition: attachment;
 filename="emacs-cant-be-interrupted-with-control-g.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAM19NFddK2Pzyh0AANz7AAAsAAAAZW1hY3MtY2FudC1iZS1pbnRlcnJ1cHRl
ZC13aXRoLWNvbnRyb2wtZy50eHTsXXt327aS/zv6FDjOnh67tWW+H75hetPESX1O6mQdp3fv
tl0ePiCJNzTJklRs73b3s+8MSD0IyLYoUYnVKq0piSSAmcFjfhgMBlExij55197fo0xSpZP/
+zeSFcS7GZI/yDCnGaFXXlD0CCG6ZFgkK4tjCX6QixivinWiWOR4lF7R46jO6BhSpcUxS3ek
2H35uMiD6ic5OrrJrxz2vX9Fk7Hv5d8O0qQ8wUtByyPNqt85Ze9kXkInL/azNBtn7rd9/K91
olliMSn+INM7EtwZUuCozG8dS79RFeBeV23dnHH/4Tu8EulEkualFAmyHIY+Ocoq2S0tpt6b
848s5f4r6kdeQmS1rxzJB+yz9zLNbvNoOCrJ/ssDokiKSl7nlJIP6aC89nJKXqfjJPTKKE0O
yVkS9Htvo4AmBSVv3r/9rH53QjB7+E4+07yAt4hK0pzEXklz8mxUltnJ8fEwGffTfHgcV0mL
42EW90flVfy8dzmKCgL/D7DQoi70hNymY4Kls9tlSoKRlwwp8ZKQ5DSMijKP/HFJSVT2IQsK
b0Ie5+/IP15cXLw4v/znISYqR5TQm5JCfWQ0v4rKkobEvwXiriHVbUbJXjFKr0kAMoiS4R7L
vroFVOReUt7uQU3mJKSlF8VFv6L2zasf4HkByZJBNBwDPQR+7d1YhmtoR3GUjG+OgOM9rozq
ZSbJKtfGrVkZr+GRPx4SrNG8BLpIlAC/4wBfKw5JFlMPxF9QetJjAi5AwtfX1/2JlCdSPIZK
P4aciuPnkGsEvKFAkPorLxl7MWM3hXvAYBqMoY2XFSk5LdJxHtCCpAmwA2IvT7DPTuvzztIa
+WCxjJsRjTOoECYM/D6VjJflKTRbcp3m4R7WWEG9PBjV0rkCMsMCqMHGFOLjPfZiv9/vXVAv
RNEUt1d+GmPzSa+W7xKYw4uy9IIR5gEZAx3D3Ls6WT6LQ0wDIipYb+z9ck6vydt/vIdfpvxb
46fS/Kk2f2rw83KUAzvQAqCyhkjRuMBrHPkle+JC56WJ58c0/K33kT0bpUXZfAF+5F5+S/ag
l/nHfGM8nn+3X6R9GSpBupHgn64bA9mW9EANDWhqxI/CyMUmEH+mLr3JoNNGMDqwBsCeRaVT
f/4dqhqGNenGHAyobwaeRzXrAJoLe7EfnMgWyAYvTyBtmsYEO24ydDPiTPI6el7d6xfkjz/I
h8uLs/M378k+/zSuPg/+1tuHhnZArrHT957C+NmCC8bD/kpMPJWFkkIpFEq6pt6n1UpRFFnr
PVX4UkLfs4VSoKaDT7QsVizJsoAfVShpYIolJXRc5l68WkGqJEu9pxpfENU8eVoQjgpuOoCC
bkoXRvl8VgyXMaNhLnNF1ntP9bpNxvQzje/I515yhVwtpffU4EkeGBKdknyVgmDK1P0cFTCK
xreszBUlpFnAhNkozhpQKTQ9LA4QBORCQUOkOZY4K6gpHk2WDnHUpl7pZs6zNCujq+i/YcxM
x+VzVt4N6MwMCrR0rHuLKzAMfIu1ZcZaBIUmLiaIvVsXFQCUPS12EVesfKAP5Q4DpjP7Wr+r
SLLG3rjBZzf13SP5kKSZk2b175/e/XzqXr5z37/70CBalhTsgTYvJtm3rHmqW1J5N1Hw8xbv
3Tbvfa55+zxjjGfB4gg3FBWGDokjXNWtAAmHKoNqcq+iJHKvQUEDTti/BpLZe57qa4oGJNMb
L8B6BQxAD3pHR0x3Prs4vXzOFOVVmtND8juqsd/HUXlIAgaYAIDC4E/JdVSOoBmQzEPVcnQU
TFr8lEjFNHF8k5tEBrapskaIGbg0GKUuaHnP9ccgz7wStEjr9SgKRg67TirgkAwSZ5BM62Mi
BE3RJfJMFIErPz8knixk7SlwS5WaAlY0BfqrrDRpH+iKYc8JeEY9k2V8S/a5bAwmArXZ7UOq
Gaxb1FjEjdM0c+U68Sd666deHmJ6XcHkWiO5rBuqaWLyKIE+nHixC5USRgiN3AAgXD1kDMaJ
g5emgKB06JUgoGbZIBpAwmEMWNuZfJkmtEFKI8xutCg7aaBhdlehS/M8zatxgX72YmRAM0H5
yHqT/8D2B4bAv0L27yNhOqLOy0dWsRsYvHyUUG7KxyuDUSWW0hs68DfNWJYkC5vSOAkcvPDs
Aa0hLy0FG1I+dOBvnsB5vmXbBMJMgW9b5vleUOvwDxJbXKORvIFctb1gDDMihB9Q6YuajamA
epRtPj01JUz/upmBmNySQKgKN7Z4ajBQ2KDowWUfWA8ck4nh89xYCLKqRqoKDgMm0BV7h6x2
yGqHrHbI6q+KrHa46E+Ji9YHzDtktUNWXSCroPeyamRo0Or918tebfiTyR57ew85o0BWSIpo
CNVGPpy9OTu/RMM71GM+zsqm0U6mFihrpGlQBjmuObjD+DaDYYlZvYvaaocPHLw0q9bTZdXW
oepZGkdRDgl7HdcqoqBw6k+uPZiyApqOPKufVo19Ujzwa2s9W3tCSDQg+z+dXl6cvfzgfrh8
cfnxA9kPvGBED4jjkMmTs/OfX7w9e3VwL/Z8iM2qXS/P5doM8pAVCDQHaoPAEtGSSB9PVJCG
dK71SIYRHJKEkVo48ozUZYnTsOMonDofmKbEtOIQUE9Gc6an3SqLija8ofgCIQtIbugHxbZk
lQHe4ThyszwNxwGt6qbgkJQZ0GZaVbYtlcewCJgsW1odMGExmwRMti3JDBuvg5fWIXIdACUg
nApEGTw3iuYP5rn5TPMyChgg92F6dA2D5MNwMLx1wgmRqq5x6M3SrAXoXJP17tCbJRkiHt8m
9Maj8lXRW0OPtUdvDfz7xdFbB9hLafLfNfZSefksxl7rw9Avj940QXIt0BsHeVujN4NP3wq9
NZFn9+itQiodYDhJ9+v2yEwbAwqNpTazTNRDUzdYml4DNf+2xPXp6g52ehd/Tb6I4/JAsuqU
1Ts5qIfptwWv4zDOXq/WXp3qQ3jRN2XIVxw1K+yZe1d0MgZWYzW09JEb02S+LGpAFgkyWjRv
S7wdSUaLBV6e/E+XsBqhEbNwTcAGjSl6Mtyn5Jr2H1VXe3ipsS+uXQ88gEN+euNmAr7tpjwO
iCJ8MoOG7m4HnzZtb7It6E4CPm0Jn76euUnlCe/e3MTj4W0CLDwsXhGw8DbiloCliSq3ELBY
HP8dAxZbkM9jMRZJAt8t4IbMNZq2cEPh07eDG2qz6XcNN4IV1RqIDsa4urHD93FJ3aJMGUAA
gHGVcctBQYhGiXpcNTSZQxrsTv2jrktDMWBkS0J8LMv4YzFamLXICU20qjy1h5cnhP2DISum
U+RDntU5i/ah+xirbRpLMNfga57T7pgTbEUw+aeTZj1loV5imiyk1rRXH6ICbDDS1M+M4ilb
c+RXSlJUFbNFPn55C7o54JdpAtm0Lez7tQSQaYFhBdfARPVuSmwAZninxjkuemzWWmzBopug
Hm1dM0QFHA40hQ2Nd8Gph3BEE1JJhrHIIrUFkGpNi9TXg1SC8al7SMWbmbYJUvH2qxUhFafz
20IqTjNvH6Ti0UHHkIoDD38qG5AqSK4FKOMMSK1BmWBDagfKjGbn6RqUrYjJGizpvmewwYjp
YbZANnNMKUqvpEu63lvMClN7F4WiLmeZjLMQcnTTJL515r7XmQ28uKCM9drWYsl6D/6eADj7
5ps5n/wJPHte32Nk/xKFN+SIyL/168cP+JM9yHg9iqzJ9wosix5pIfw3pXUAg/nEUczNvChf
0lsMKZ0vSjFUwRiCZQUDaVrWan5pQkmQ7Ub80viCOvNLYxlzlr/1/dIW57pRvzRBQp34pVUr
iF/PL+3hFUxZt62HQe3+BNX+DLCW/EHmQS6HFu9wVPPsFjB3HbLvw73CoDPPo6wsWHjVDJmH
VWzhVTPmuVl74ZXDlJKlKjwYYsuuRqNYv2oDBdkPGXuQ6cMTNBmqyGRQaAXk3oSslmyIFpUv
itrXBWqktybubyKnlXG/AKBa4n7Br2zbcL/of9Yp7rd4+TwWU6ot8L08am86vrVH7Ypgim2F
2hXOaXV91L4h8I7qR7VYr/zhn5enqLTcF69eXZD9xDF1e9psltlTXI1i/RGM0arUwwtg7pyW
4xxYTsgz8ub9pYulkO+JRE7Imxfv3Q9n/3l6QL4jCfz9cPqmKvuIfcU3790puznaETy3MfTN
j1q2rgs7NTZj5BMMidtg5OMtk1tj5BOsk90b+Xg74heFC2sqe342sKKy59cNWyp7cV1w25S9
uH7YqbIXHOEei7IXHdyWV/bC3o6Wyl408bVS9k2A2oWy71rLoy3Asma2gMpShVPvCU/1zN6Q
tR78PfnfB+xey+eGqvRu+8OStgfe3GFIyoIluk3bH0R9u2n7g2GYD+vbtvYHUQN3bX+4k+wN
2B8EtdyV/UG38aN+vsD5WxUsbhtx/t4t/O0W/h7Hwt+XxwRfcdluXeNZ8AgX/roEF43lllmA
rYe0uRBsQLb1Hl5qh+M63dFzFmjNccj56cfLixdv3R8Onhx/S/7DIt8eC9BkHVo4ZMHo2QVz
aF9QZ4tmu2AOu2AOu2AOu2AOu2AOd2KL33v/Dm91v6PLdd+cua6b1TE24cUrr/gEsDK9duBv
0r8PSUKv8ckd/jn1U6FT+gZ6/KZxyNLWn9O3ZgC1f5xkZXzMkQGVp6k9TX1y52NynpJijJFX
0f0aI95GwDQMp7f9WlZMOB+TkA5goAsnjeWE7OGDvT4hlxh7tI7u2rl4G01O02TLnIz7QJA3
jnEorpof2a9CwiIuVlUQGqDiMToxSxMHb+h/gxig+IfTSxfKOb04B4z08fyHs/NXrZY9YuxW
oxPFls0eXmYLNt9m90cpvZ+DqsfczcVGGBC81HUTZulIYpi6Kai2cYLlVrSNExzE0Am82s53
H0WgEUZR4fp1gjk9o2qNeQuCR4B1VTmgo8h+kI6T0mHXuqn3+/2JKNh1rgfM5aSahrTIVVyR
GTipRhSX7c3DjY/LeJ9rpm4u8AzXNd+YyxL3Hzy0xKXJqiZaXkLdMusZFqKTqX4WRglUrUwK
MPYh/feiGNMwJdHQEuoD1a9G7GiGm+4u8lq8NYEGwoPJxgPhQZ4uyMYH/VDVQyQ47glVoOqI
ERaEDNC8zjCChW5yu5ABu5ABjyNkABPLF7QarQuuiGg6amd3+nOHDFgR+/zpoeUMJG0BqwJQ
8qmmMc8RQC5xGnxyPaAIRgKyDwUAvuPKnxZSvYZtz2DApyi9vKwT1z0fOqODl5rEF5dnP51e
uBenb+Hbz6eArOBdSHaV1ZBgkXYJJEWB4QDPoHChs+bD2CsKVOFxBG+6oVd6ztx3DlFNiZQN
TbSFSeHAqgwwjPZp9pxSUU1dl0UDV0hNWVlKqWiWAJm2UKnw1rKOlYq47f1xKJVF29mXVwnC
+lVblcAjmZYqgbMXPRKVwOymi/cKiVZhRbMmc9/pLpnJl7riqmncMjtlJs2vNsxastaDv3rz
9nQVoiKNjQrkGcF9Qd98wz6ezXs9ICJdvCDx8G4gnr31OeO4EhcyBpbKxpsNGLcXxOzbuHG7
Y4+MZYzb5hI7Qh4wbnfvAnkXUR0bt3cukDsXyM1jjJ0L5AoY4+u6QK476Ra8JR4NSkF3fRxn
62C9GOp2QaRZJfQWR5oFxh1d9F1TbBXUF7vWjg8vf3xxwXY8WO57KOBADBazSUoQKDwY/VYw
A2P02wVaf83ot5tWwlX0WyEK2rboYAE8dK+DeTW/TTqYxw8r6mBzPR1sbbsO5qesXetgiZfP
Y9HBoqtlCx0shF9rqYMFHd5GBwvbbR+JBl3PZ2t+jqnoVg8vT57Uu/OYOoTxc/4gznpAJt/N
blUhWf/WJVONeqKKoU/39kGtXHnQRFL/XzQoneqj2UR9OVD0UK3tGawLuhGIJp2kdhbcq7Ng
8/w6pTcu0zj1QmfyZf6dSROBpNhAbasHfzXYOD97+35C4QKk8RBzVbdchsGVeGvJlmDkoKpk
MWO2F+DZtnUZ2Ouw+MXW9hkRNQshtWQlABai8AbuhSFa3Us3/eTgpUlwkkYJCA+a8vTbchxN
wwZMGdIMU3QMpZrkBwJDVS1Ms66MRDNS6qIrktkz5ETgHkXSZJkjyLYZWIJx79M4w6JduSq5
rs5GDfLCg4f4wlzXNmWfHcygh4eMnWzqO+I0f07TSFyVK6awixRFJPvVUDkjtEHml6BMxZAP
Ok+Z7hsaowxlV7uQTElbtWSsaTenyNnky/QhutpkdUxGZ/LlTqItxRDN+lQPPaY6Xk/0Hisi
m5Je33bqz5lutikgpfsJOKxLL+q2U9xd1ZpgVQGtGABEq7SqF7IGWdDfxzQJ6FSqAEyd6kNQ
Kj4L/wjznKusdKqPecpCPPYEkGeCqMyNvaJ0xFvNzh14GPkSfabcAgByMHJZuHDnjvtzXR8w
THTjgmbP4V6Nph3xViNFloMmhUfsAHmcUjnCnUXD5RSoSKYqLzAxhdTQl4K3qiWiw+2Dtx2Z
mNY1e5CdkaodQF7LSPVYTUwVTagGAnkgBVoVOe3775ELjDtB8Nz74xvLcA3tKIbCbo6GyRhv
Bl6Up/0i7St3YDg+01owy2Q4g1XTTKzK37NNJkozE+pr9YYQ9pJbBF5MQ3d22FSZTm1PMzfQ
ZQrilvVlatnVStf0MCvQEGlI2Zyh6jZ3GMkWrTrNHU6lWgucKAemEZoTkMwZ6WqF2cpQ95Af
oWKrdrX3dWWrneBRuQ1WO8Fzclusdrw/5gasdrzb5DZZ7fhdMyta7YT4+e2sduJG2G2DNeKG
2VVgzZ2gRNg28zhAybowbMFe3XawRnDZbAlrTD59O1hjNTvP+rBmByN2MGIHI5YncgcjdjBi
ByP+6jCC7HDE5swjUw1pm9Vq1EMKSzyrWYHBoMeuc66+r9+dX4KieOf+ePbmx0qZ378i1poG
fpyt6Fhw6OFaivPhqFxdKM41Dz1ch8h1NKmg6u44CfFLnRkt+PB0HzZs58Oz8+Hh+O9ajUu8
fB6HGt/58GxUB+OhN9RmQQiqQ/SqiSqTK02G5YjsV5/Os+I2KUcURlCSpaxRTLwtJsvxihRa
nhpaZI+YkgoTbU02VUMiSl9VVAvmpqpNdOngV+Ac9I9u6aZKYOKsE92WbVXTZKJqtmYTGcdV
TdNnuWiSjLnAa6YKTY3o8sFvvya/7u21Ci6BnMEAw+KCq6begz/0oElKQIIOyX6Rfrs/RsZD
oqr6xn3i+pqSWlVK04ivs2PAZ8YLVNdNlQ8Fm7OgC9UvHMiXOQe8erzMEeCrnf69/sHfKMTa
f01WLUl07tEDw1KxiTCR8VHsaqXS0lNOkbRFRyVtJIqdEPItNIwZP6seMyWUZYr7j7o5Zkoo
iR0zJUSF21TEPB6kdBoxz9pIxDweV2w4Yp4QUW3Tmwr5/bLbsamQj6y2aGq2roUjaMXnZuZy
C+Zx/ClLG7CK8rhsm6ZTvNvLitMpwTrVbjrFGae2bzrFnZPU+XTK5uXzSKZT/ElKraZT4jFK
7aZTijAdazWdUjZ8on0n0ymAstpUfdZRBaiXB6O7EDMMb/VEKoxyQL4TD1EYK6sz0I/keTVq
GFIP/uaMnnV2jUgGv8wVj06ubhTeTE9BfWCPwN0s3Af8GRtLcyDGMvCtuXDJVaGDaXi/SZGs
kEk8hSp4QuNXXXDty9sWoVjmAnd9PfTtWZCFjlCpZQkGyw2i0l0c54dQ6V8hjnMHqLT7OM5f
ClPys44NYMpdHOcvHce5ownQY0Kl4oJzp6hUODz1kaDSBYeiLo9KeSjfFpXyJ5O2RaXc2NI1
Kl0rSvVC0NJeSyqWofXwArAzK/MwGgxcID31u8TRWxBqcRdVMtpFldxFldxFldxFlXxIif3e
e0FC6o+HiLVgHlUU0GBJVBAAkEBMv9d7cpYAEo5gpJTJL1me4m54okuG9RsgtTgmPoUMSrQE
hPA2HpJBvOT22rv9nuzf4gCbHJCkd56WiPAGUX6F73Woj4qxXy3xlp4f44mYA2xP8JVJALd5
K6FlGyH6ZsuKilOZqHDHScSWMJvBKTEfSNtnZ1LhEVn/396V9bZtBOHn+FfoKbCBpqBI8Qqg
AHFsFQbkAz4KBEVB8FimRm3JsORG/ved2SUpcmcliodsqeVDGJs0d2aX5M63O/PNJLkbljdg
Psq7i7Or68sr79vl+dX16c3N6Yk3urw+xxxS8KIpItm2pyLdoHFsk+8KFeWlnxnKpEn5h+kH
xoUfSWIGpOyn23cdPeYrM55C6/br8fgUDMEoWVaqch6EpEBApaiAtOSEhiUnYOJHv72/4M5n
9jx/9bj+MP73fnYu9Rw3kivk8BLlJrcZsmC+bsQaFrOtSsfJA0zODAnuM7Z4mnmwklrGxvFE
p0N+pDDD9LlXffpIn4oosf46V7wVbBINWZZloG/YBlh4mFnYPGIARYa5n9M1vqvrhgHznGE5
5sC2TQfDBbC2RcBAW9Qv/TG5I2Xzw8wLJ/DyUMzYScfBWBs69QzD6xcLH/ToyX+eMQ+O83sw
KTgyYkDU3Z1PFedyfSIXc8prCwHWxFDT9zvfh4XcC6uvMIm+ZohKKWzBQv4UcqQTtOxECKg6
8+bs8elBqcMEr6vvUm52oUiUyM2Lq4i+s0OLQ4IRGmEfJvtDIaKfNJp7yezcHmFib3UXS7PQ
vAVWXwICBaDkTUqgUuiGHEL6MUxtLxPAedO/ZxwsCeX4cYnN+bncqYLO2jqEZaxDWGGo+VQL
BdgyTUVdDBDu8kdfuN9LhlkMgOiNrhjqWJPRQd9xlQkMgoHYP0sF8NkK2ysXIeAXaJPrsx9o
cp+Fzs33eB4eCsOmwwxCAwND39ZMMmwz79F/DeDF8WH0f7JkSsQrQzxkTy7SETOTcjJkLF1D
lTaBacGGu2T9Ortk69/5t18edHtcNZYH//E9rpoIXejEWaSaGznGgLuINsm1ET8zhjsOSBS1
1vFkc+2WUVyLbUpUWc1lutEPa7SjS+0AQvZ5O6Nb7zc2974hHj+bRGzR24AeKzVuSI2bgLJ4
vN8ohDeD4dyL7W/ePDxUvhr7gQLymyFLwrBrbTIKeR6vWWxke4RhGQ5ulzBMMoy/D2HYaUAY
lj2CDXlP2/ZjCt4T8QbujRtT2qXZhhtTcgXulRtTig+q68aU81JVdGMW8c3eAbTmiJsEF7YN
8Ujw4a5APBpUWAHiEYhWDeLJkX1VIV7rO8DbgHi6728F4iXtloGSDuJ1EK+DeFuHeI65exBv
lU4dxOsg3v8N4vU6iNdBvJYhXtKlWPddPt9h5LWYgbzsmcPrFKSPMYp0w3WWr5D4W1RPd60D
PHxIOBIfP/Zuvp8fX4694/HvvcPZ6+PRpy/xz+hX+Pc0fy5hQ7SkEPGnQ7uxuardPra7yrbn
Gsb0I3IWlyAOXO6of5ngNOutmdX/4fFp2fwb2AM/juRp11Ek0jNtK+axYNHUm4LJf5kEGVdD
iEV6tnBU4xV0Yw9vTm89ePan1xdfx97dxfHZxQmYyr/uZ2ke/fxLZ1uFj8+wdEFkEJLAfANS
mr4AJuLH5JPl0WFwwwsb8mP2JRfbsi1NmVJlYJVaQeICfQczaHc5Vdoxg11OlVpGrMupoqos
WGd5BdM3P+bIfLjO6w2HvYu78VhRNbCmlLbzk73NIq5hfrL3W8SRVGTtL+LkpGP7tIiTTW9N
6yXHGVe0XjSOeM+slyLeuE3rRcOrdsV6aaTfFaxXQwo7tX7VrNc+UNijwA1QpxXkIf7EyxhE
jt0XKucpz3hIbB1uUKeF/pZs74yZtKby3y89LaN2H5Vl7FrbleSLrtMTGh7dnLwtCxLkbcJH
r07e5g1nq8c8edtoQN5Wt4qrRcI3b4u8TUaIk7dJHfuK5G2Rx7QCeZtmSQ+akLc3yaPaBEwl
5O2GadKbaNkEXhH8syJ3+ltleyUc+PazvcrOi33CdrL/oia2I2a2GraT1ph7h+2abtCH1MXR
MjqkLpBdQYfUMVEBHZKc6xXRIQnTrYYO3eLHs5PokA3CJf5QAYeN8CEtBw0PDw8fsns/fUlA
Iv5XBvRKtNoMXyiVolCvLTijzkVDdj0qwpnKuWjk3YqGcGbbe0MJnCFZ16vBmffbHCJwdfXm
0CrTXgARRetp052R/QIQJGKmHoAgNXGrAYiuJm6J+e8q2qrM/65VtEWs+CY8/NeDE/4nKIOH
ZUI7P579x88bsZH5r7yOdyb74I+cVof5K0eZNn8e/AtQSwECFAAUAAAACADNfTRXXStj88od
AADc+wAALAAAAAAAAAABACAAAAAAAAAAZW1hY3MtY2FudC1iZS1pbnRlcnJ1cHRlZC13aXRo
LWNvbnRyb2wtZy50eHRQSwUGAAAAAAEAAQBaAAAAFB4AAAAA

--------------kcjWW2kzp4JrMOBLWEZZB3WC--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off?
Resent-From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Sep 2023 07:17:02 +0000
Resent-Message-ID: <handler.66096.B66096.169519418410261 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 66096
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 66096 <at> debbugs.gnu.org, "ishikawa, chiaki" <ishikawa@HIDDEN>
Received: via spool by 66096-submit <at> debbugs.gnu.org id=B66096.169519418410261
          (code B ref 66096); Wed, 20 Sep 2023 07:17:02 +0000
Received: (at 66096) by debbugs.gnu.org; 20 Sep 2023 07:16:24 +0000
Received: from localhost ([127.0.0.1]:58187 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qirRf-0002fQ-PY
	for submit <at> debbugs.gnu.org; Wed, 20 Sep 2023 03:16:24 -0400
Received: from mail06.siriuscloud.jp ([219.118.72.6]:37309)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ishikawa@HIDDEN>) id 1qirRc-0002f5-QF
 for 66096 <at> debbugs.gnu.org; Wed, 20 Sep 2023 03:16:22 -0400
Received: from [192.168.0.77] (M106073032161.v4.enabler.ne.jp [106.73.32.161])
 (Authenticated sender: ishikawa@HIDDEN)
 by access06.SiriusCloud.jp (Postfix) with ESMTPA id 4Rr8vr3hppz5gSZ;
 Wed, 20 Sep 2023 16:16:08 +0900 (JST)
Authentication-Results: access06.SiriusCloud.jp; dkim=none
 reason="no signature"; dkim-adsp=none (unprotected policy);
 dkim-atps=neutral
Message-ID: <4cdbc18c-9e36-4319-921d-fd99302ac957@HIDDEN>
Date: Wed, 20 Sep 2023 16:16:54 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
References: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN>
 <834jjqe85z.fsf@HIDDEN> <80682fbe-b5ac-4605-b8e5-7baac2d71da5@HIDDEN>
From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
In-Reply-To: <80682fbe-b5ac-4605-b8e5-7baac2d71da5@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Oh, I now notice that you are saying if resize_echo_area_exactly is 
always there, the backtraces won't help much.
Tough.
I think the routines called by resize_echo_area_exactly do not change 
the environeent to satisfy what resize_echo_area_exactly wamts, but
I think that will need detailed debugging.

Unfortunately, the problem did not recur yesterday afternoon and I could 
edit the file after "recover-file".

I will try to create more meaningful debug information when something 
similar happens.
It was really the first time in a few years when emacs could not be 
interrupted by control-G.
So, I am not sure if I hit the right condition easily.

TIA

Chiaki

On 2023/09/20 16:09, ISHIKAWA,chiaki wrote:
> On 2023/09/19 20:04, Eli Zaretskii wrote:
>>> Cc: "ishikawa, chiaki" <ishikawa@HIDDEN>
>>> Date: Tue, 19 Sep 2023 13:12:33 +0900
>>> From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN>
>>>
>>> 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.
>>
> Thank you for your comment.
>
> There seem to be enough variation of the stacktrace patterns.
>
> I am attaching the gdb session file as zipped archive.
> As you suggested, it seems Emacs is trying to resize echo area, and is 
> looping somehow.
> resize_echo_area_exactly () seems to be always there.
> It could be that it was trying to dump the S-expression that encodes 
> the latest GC information after each GC.
>
> I have the following code snippet to monitor GC issues on my PC for 
> quite sometime.
> But I have not seen this particular problem before.
> The long pause I have seen before was strictly in GC-related routines.
>
> (setq my-gc-statistics (make-vector 30 nil))
>
> ;;; The element is
> ;;; (append (memory-use-counts) (list gc-elapsed gcs-done))
> ;;; Each time the following function is called, the
> ;;; elements in the array is shifted toward the end.
> ;;; Use (message "%S" my-gc-statistics) to force the
> ;;; recording of my-gc-statistics value in *Messages* buffer for later 
> analysis.
>
>
> (defun update-my-gc-statistics ()
>   (let ((i 28))
>     (progn
>      ;;; very unlike Lisp
>      (while (<= 0 i)
>        (progn (aset my-gc-statistics (+ 1 i) (aref my-gc-statistics i))
>              (setq i (- i 1) )))
>      (aset my-gc-statistics 0
>            (append (memory-use-counts) (list gc-elapsed gcs-done)))
>      ;;; print the latest one last so that I can see the glimpse in 
> the narrow
>      ;;; output window.
>      (message "%S\n%S" (current-time-string) (pp (reverse 
> my-gc-statistics))))))
>
> (setq post-gc-hook 'update-my-gc-statistics)
>
> For example, in one place, I see
> #0  0x0000556f1905be9e in string_char_and_length
>     (length=<synthetic pointer>, p=0x556f20d8a3d8 " 70337 417360 
> 2.323839139 50)\n (99058573 3875 59193441 34949 11084445 70337 417401 
> 2.391973008 51)]\n\"") at 
> /home/ishikawa/repos/emacs-29.1/src/character.h:375
>
> And that string is probably   from (append (memory-use-counts) (list 
> gc-elapsed gcs-done))
>
> Also I see recursive_edit at the bottom of the stakctrace.
> Not sure why. Maybe I was doing some error recovery of Japanese input?
>
>
> In any case, Emacs should not enter a state that cannot be interrupted 
> by CONTROL-G for a long time IMHO.
> (Or was it that the processing of control-G somehow resulted in the 
> effort to widen echo area and emacs failed?)
>
> TIA
>
>
> Chiaki

Last modified: Wed, 20 Sep 2023 07:30:02 UTC

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