Received: (at 66096) by debbugs.gnu.org; 20 Sep 2023 07:16:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 20 03:16:24 2023 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 Subject: Re: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off? Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> 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-Debbugs-Envelope-To: 66096 Cc: 66096 <at> debbugs.gnu.org, "ishikawa, chiaki" <ishikawa@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#66096; Package emacs.
Full text available.Received: (at 66096) by debbugs.gnu.org; 20 Sep 2023 07:08:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 20 03:08:34 2023 Received: from localhost ([127.0.0.1]:58175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qirK5-0002SQ-MW for submit <at> debbugs.gnu.org; Wed, 20 Sep 2023 03:08:34 -0400 Received: from mail06.siriuscloud.jp ([219.118.72.6]:41118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ishikawa@HIDDEN>) id 1qirK2-0002S5-5C for 66096 <at> debbugs.gnu.org; Wed, 20 Sep 2023 03:08:32 -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 4Rr8kp22gVz60Nb; Wed, 20 Sep 2023 16:08:18 +0900 (JST) Authentication-Results: access06.SiriusCloud.jp; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral 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 Subject: Re: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off? To: Eli Zaretskii <eliz@HIDDEN> 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> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66096 Cc: 66096 <at> debbugs.gnu.org, "ishikawa, chiaki" <ishikawa@HIDDEN> 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 (-) 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--
bug-gnu-emacs@HIDDEN:bug#66096; Package emacs.
Full text available.Received: (at 66096) by debbugs.gnu.org; 19 Sep 2023 11:04:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 19 07:04:29 2023 Received: from localhost ([127.0.0.1]:55478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qiYWr-00008H-4h for submit <at> debbugs.gnu.org; Tue, 19 Sep 2023 07:04:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qiYWl-000081-Hs for 66096 <at> debbugs.gnu.org; Tue, 19 Sep 2023 07:04:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qiYWV-00022e-5b; Tue, 19 Sep 2023 07:04:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=7m+fKzMVdJljJ+Mf7ebAu3sLlrnyyJD/V1TK+HpHR9s=; b=bRJBFWGeCn5sKo0JaxJp XWrGgHdX2JQWlQ7Tz9LUkOVMAmMjJp7YKZDDQdcK8eldBqny95U+5zyknYPnIAgoGtHlLObYO+38N f38Jl9QT6sCx/FLq+KO5IrHqTFFsgrhBYWoodT18Zj2I0h+Nq7NbqAD6HXV0Vpul7NOkJ4aej3frU vd7u8gw/Y5+EoRi8VWxM2UAbbncyGr3OXe8wDXCAKuuqPnzVE8gJKljhIJ74mccJZZlfM6e+Y6Ezl qYJ2KY9lfToYOBiAC6HQwlytkDvPuyN3obVBa8m4dGArrg87oljYPZhJ5EbsJjNEHDHgtStXafVKa zy/bhr7bDaA5pg==; Date: Tue, 19 Sep 2023 14:04:08 +0300 Message-Id: <834jjqe85z.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: "ISHIKAWA,chiaki" <ishikawa@HIDDEN> In-Reply-To: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN> (ishikawa@HIDDEN) Subject: Re: bug#66096: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off? References: <1808d5a1-3ee6-d675-3ad3-c6bcc2fe5e36@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66096 Cc: 66096 <at> debbugs.gnu.org, ishikawa@HIDDEN 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: -3.3 (---) > 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.
bug-gnu-emacs@HIDDEN:bug#66096; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 19 Sep 2023 04:12:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 19 00:12:22 2023 Received: from localhost ([127.0.0.1]:55103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qiS62-0007eL-78 for submit <at> debbugs.gnu.org; Tue, 19 Sep 2023 00:12:22 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ishikawa@HIDDEN>) id 1qiS5x-0007e3-7O for submit <at> debbugs.gnu.org; Tue, 19 Sep 2023 00:12:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ishikawa@HIDDEN>) id 1qiS5i-0007FJ-TV for bug-gnu-emacs@HIDDEN; Tue, 19 Sep 2023 00:12:02 -0400 Received: from mail101.siriuscloud.jp ([219.118.72.101] helo=mail01.SiriusCloud.jp) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <ishikawa@HIDDEN>) id 1qiS5e-0006uN-Pk for bug-gnu-emacs@HIDDEN; Tue, 19 Sep 2023 00:12:01 -0400 Received: from [192.168.0.77] (M106073032161.v4.enabler.ne.jp [106.73.32.161]) (Authenticated sender: ishikawa@HIDDEN) by access01.SiriusCloud.jp (Postfix) with ESMTPA id 4RqSsf6Pjlz35twCJ; Tue, 19 Sep 2023 13:11:50 +0900 (JST) Authentication-Results: access01.SiriusCloud.jp; dkim=none; dkim-atps=neutral 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 To: bug-gnu-emacs@HIDDEN From: "ISHIKAWA,chiaki" <ishikawa@HIDDEN> Subject: High CPU usage, basically runaway emacs with visit to bidi_cache_search on and off? 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-Debbugs-Envelope-To: submit Cc: "ishikawa, chiaki" <ishikawa@HIDDEN> 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
"ISHIKAWA,chiaki" <ishikawa@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#66096; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.