From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#70423: 29.3; cc-mode hang at 100% cpu and consuming all available memory Date: Thu, 18 Apr 2024 18:39:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12084"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , Bob Weiner , 70423@debbugs.gnu.org To: pillowtrucker@proton.me Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 18 20:41:18 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rxWhB-0002vQ-6i for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Apr 2024 20:41:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxWgo-0004rn-Qy; Thu, 18 Apr 2024 14:40:55 -0400 Original-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 ) id 1rxWgj-0004rS-Cb for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 14:40:49 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rxWgj-0007fv-1R for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 14:40:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxWgw-00089x-K6 for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 14:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Apr 2024 18:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70423 X-GNU-PR-Package: emacs Original-Received: via spool by 70423-submit@debbugs.gnu.org id=B70423.171346561631059 (code B ref 70423); Thu, 18 Apr 2024 18:41:02 +0000 Original-Received: (at 70423) by debbugs.gnu.org; 18 Apr 2024 18:40:16 +0000 Original-Received: from localhost ([127.0.0.1]:53970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxWgC-00084t-53 for submit@debbugs.gnu.org; Thu, 18 Apr 2024 14:40:16 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:30172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxWg9-00083y-SD for 70423@debbugs.gnu.org; Thu, 18 Apr 2024 14:40:15 -0400 Original-Received: (qmail 9441 invoked by uid 3782); 18 Apr 2024 20:39:54 +0200 Original-Received: from muc.de (p4fe154b7.dip0.t-ipconnect.de [79.225.84.183]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 18 Apr 2024 20:39:53 +0200 Original-Received: (qmail 10028 invoked by uid 1000); 18 Apr 2024 18:39:53 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283607 Archived-At: Hello, Pillowtrucker! On Tue, Apr 16, 2024 at 19:51:09 +0000, pillowtrucker@proton.me wrote: > Greetings! > I have been able to replicate a (relatively) minimum environment for > this — hyperbole + clang-format.el. I think lsp-mode aggravates the > issue somehow, but is not necessary to enter the infinite loop. Without > lsp-mode, however, the memory usage seems flat, as opposed to > ballooning when it is present. I would also guess that if you are able > to plug in that regexp into cc-mode without installing all of > hyperbole.el, you would probably get the same effect, but I didn't know > how to do that. > You will need gzip and the clang-format utility for this from your > linux distribution or compiled from source. Preferably version 18.1.3 > of the llvm suite, but it might work with earlier versions. I don't > think /how/ it's formatting the file matters as much as the fact of it > being altered to some degree. OK. I haven't actually evaluated your init.el (as I don't fully understand it), but I have a strong hypothesis for the looping. You're loading hyperbole as part of the initialisation. This sets up the value of defun-prompt-regexp to a ~760 character long string, whereas normally in C++ Mode, this variable is nil. This variable is what is seen in the second backtrace below, although it is bowdlerised to a very short string ending in ... . See the line below emphasised with <=========================. This regexp is known to be faulty, and sometimes to cause infinite looping. By coincidence, I have recently rewritten this regexp at the request of Bob Weiner (in the Cc:), the maintainer of hyperbole, and he is currently testing the regexp. This faulty regexp may be the cause of your bug, too. So, could I ask you please to be patient, and wait for Bob to complete his tests. If they are successful, a new version of hyperbole is the likely outcome, and this may solve your bug. If there is any way you can run your test without installing the hyperbole package, please do so, and let me know whether or not the hang still occurs. Thanks! > Please follow these steps: > 1. start with an empty directory > $ export MYDEBUGDIR=emacs-debugging > 2. use the attached init.el file as follows: > $ emacs-29.3 --init-directory=${MYDEBUGDIR} -l init.el > 3. Wait for the script to reach the point where it's in an infinite loop (check top/htop for emacs with 100% usage, maybe wait a few seconds or minutes to make sure it is not just taking a long time to run the formatting) and press C-g to send "quit". > This results in a hang and the debugger should show something like this: [ .... ] > or maybe you will see: > Debugger entered--Lisp error: (quit) > re-search-backward("^\\s(\\|\\(?:^[ \11]*\\(template\\s-*<[^>;.{}]+>\\s-*\\)?\\(..." nil move 1) <========================================================================== > beginning-of-defun-raw(nil) > beginning-of-defun() > c-get-fallback-scan-pos(18908) > c-parse-state-get-strategy(18908 1) > c-parse-state-1() > c-parse-state() > c-laomib-invalidate-cache(18908 18910) > c-before-change(18908 18910) > clang-format--replace(18908 2 "\n") > apply(clang-format--replace (18908 2 "\n")) > clang-format-region(1 18910 nil nil) > clang-format-buffer() > load-with-code-conversion("/home/wrath/emacs-debugging2/init.el" "/home/wrath/emacs-debugging2/init.el" nil t) > command-line-1(("-l" "emacs-debugging2/init.el")) > command-line() > normal-top-level() > Either way it does seem like the problem lies somewhere in cc-mode > choking either on the file itself or on that regular expression. > I license the attached init.el under the terms of the AGPL-3 or later > version. The drm_formats.cpp file is part of the MIR Server project and > is licensed under the terms of the GPL-v3. Both licenses attached. I'm > not sure if I am allowed to re-license the MIR file as AGPL, but I > believe they are in any case compatible to be distributed together. > Thank you for having a look at this issue, it has been plaguing me > since november and even making rust look like an ever so slightly more > pleasant alternative to dealing with constant hangs/crashes and having > to restore frame/window layouts when editing C/C++.. > Kind regards, > M. -- Alan Mackenzie (Nuremberg, Germany).