From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 08 14:00:22 2021 Received: (at submit) by debbugs.gnu.org; 8 Nov 2021 19:00:22 +0000 Received: from localhost ([127.0.0.1]:59480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mk9sT-0002iU-VA for submit@debbugs.gnu.org; Mon, 08 Nov 2021 14:00:22 -0500 Received: from lists.gnu.org ([209.51.188.17]:46008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mk9sP-0002iJ-Oy for submit@debbugs.gnu.org; Mon, 08 Nov 2021 14:00:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mk9sP-0001to-GS for bug-gnu-emacs@gnu.org; Mon, 08 Nov 2021 14:00:17 -0500 Received: from relay001.lsu.edu ([130.39.6.46]:41536 helo=relay.lsu.edu) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mk9sM-0000nu-7c for bug-gnu-emacs@gnu.org; Mon, 08 Nov 2021 14:00:17 -0500 Received: from cyc.ece.lsu.edu (cyc.ece.lsu.edu [96.125.115.182]) by relay.lsu.edu (Postfix) with ESMTPS id 7152C2198B14 for ; Mon, 8 Nov 2021 13:00:06 -0600 (CST) From: David Koppelman To: bug-gnu-emacs@gnu.org Subject: 29.0.50; High CPU in c++ mode. Type finder? Date: Mon, 08 Nov 2021 13:00:06 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=130.39.6.46; envelope-from=eekopp@lsu.edu; helo=relay.lsu.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Load the attached file into a buffer: ./src/emacs --no-init d.cc Emacs will use 100% CPU on a core while the buffer is visible. CPU usage goes to normal when switching to another buffer. The attached file is a reduced version of a much larger file. (The larger file [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [209.51.188.17 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.51.188.17 listed in wl.mailspike.net] 2.5 TO_NO_BRKTS_PCNT To: lacks brackets + percentage X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Load the attached file into a buffer: ./src/emacs --no-init d.cc Emacs will use 100% CPU on a core while the buffer is visible. CPU usage goes to normal when switching to another buffer. The attached file is a reduced version of a much larger file. (The larger file experiences the high CPU usage only while a certain portion of the code is visible.) --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=d.cc Content-Description: Testcase. { if ( indices_segments != opt_segments ) { for ( int i=1; ichain_length = chain_length; } { for(int i=0;i) id 1mkITx-0004px-F8 for submit@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:37 -0500 Received: from quimby.gnus.org ([95.216.78.240]:55032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkITu-0004pR-N7 for 51692@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+NAyoLuZzJqfRinnlS+zx0GpkNKTVFZdNHr/WzSINdI=; b=ie8A8mDoixZ7hGDQ2TQceWVj5V IcS/Cbe6LWQ7V4Eu2uSvfIa8+3lCX11VlVl9hwyzpIGJ3WU4uzjfxk4Phmb5polC67Cb9hjHM2c9N lSaqYMwyCPRMEuzvot4FsjrAX9plTVwgx6RhfhZihfAqeIPZNakQANhiiFi+RnASClHs=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mkITh-0008St-2o; Tue, 09 Nov 2021 05:11:28 +0100 From: Lars Ingebrigtsen To: David Koppelman Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? References: Date: Tue, 09 Nov 2021 05:11:20 +0100 In-Reply-To: (David Koppelman's message of "Mon, 08 Nov 2021 13:00:06 -0600") Message-ID: <87pmrarms7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: David Koppelman writes: > Load the attached file into a buffer: > > ./src/emacs --no-init d.cc > > Emacs will use 100% CPU on a core while the buffer is visible. CPU usage > goes to normal when switching to another buffer. T [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51692 Cc: Alan Mackenzie , 51692@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) David Koppelman writes: > Load the attached file into a buffer: > > ./src/emacs --no-init d.cc > > Emacs will use 100% CPU on a core while the buffer is visible. CPU usage > goes to normal when switching to another buffer. The attached file is a > reduced version of a much larger file. (The larger file experiences the > high CPU usage only while a certain portion of the code is visible.) I can reproduce this problem on the trunk; Alan added to the CCs. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 08 23:11:43 2021 Received: (at control) by debbugs.gnu.org; 9 Nov 2021 04:11:44 +0000 Received: from localhost ([127.0.0.1]:60244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkIU3-0004qO-M9 for submit@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:43 -0500 Received: from quimby.gnus.org ([95.216.78.240]:55042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkIU2-0004pv-Bf for control@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Pls9twTM5Tb1TJuBIL8R9f8Mx7AsTfADjhVgDbDpK9c=; b=iCslmk07ym2EAep2ViFFT48+uS DyGx++XWBrNQx4kVmPx1Pg8jLiw2inXXbsFfdpra6rmQJvNhubGIVNJ4+PUlzfbQzNDAWQLrJC8Go wuLl6IaLZgKYbpGBVWHkX94Xq/bgHTFegd42bo4hpTdLX8CN7wKH9pz/3EjjlonXCBo4=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mkITr-0008T1-GZ for control@debbugs.gnu.org; Tue, 09 Nov 2021 05:11:36 +0100 Date: Tue, 09 Nov 2021 05:11:31 +0100 Message-Id: <87o86urmrw.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #51692 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 51692 + confirmed quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 51692 + confirmed quit From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 11 14:06:39 2021 Received: (at control) by debbugs.gnu.org; 11 Nov 2021 19:06:39 +0000 Received: from localhost ([127.0.0.1]:42281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlFPC-0007JT-W4 for submit@debbugs.gnu.org; Thu, 11 Nov 2021 14:06:39 -0500 Received: from colin.muc.de ([193.149.48.1]:62252 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mlFPA-0007JE-Ns for control@debbugs.gnu.org; Thu, 11 Nov 2021 14:06:37 -0500 Received: (qmail 34005 invoked by uid 3782); 11 Nov 2021 19:06:29 -0000 Received: from acm.muc.de (p4fe159a8.dip0.t-ipconnect.de [79.225.89.168]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 11 Nov 2021 20:06:29 +0100 Received: (qmail 8947 invoked by uid 1000); 11 Nov 2021 19:06:29 -0000 Date: Thu, 11 Nov 2021 19:06:29 +0000 To: control@debbugs.gnu.org Subject: Merge bugs 51631 and 51692 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) merge 51631 51692 quit -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 11 15:00:54 2021 Received: (at 51692) by debbugs.gnu.org; 11 Nov 2021 20:00:54 +0000 Received: from localhost ([127.0.0.1]:42375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlGFh-0002W8-MC for submit@debbugs.gnu.org; Thu, 11 Nov 2021 15:00:54 -0500 Received: from colin.muc.de ([193.149.48.1]:63731 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mlGFf-0002Vr-4M for 51692@debbugs.gnu.org; Thu, 11 Nov 2021 15:00:52 -0500 Received: (qmail 69068 invoked by uid 3782); 11 Nov 2021 20:00:44 -0000 Received: from acm.muc.de (p4fe159a8.dip0.t-ipconnect.de [79.225.89.168]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 11 Nov 2021 21:00:43 +0100 Received: (qmail 9100 invoked by uid 1000); 11 Nov 2021 20:00:43 -0000 Date: Thu, 11 Nov 2021 20:00:43 +0000 To: David Koppelman , Yuri D'Elia , Zhiwei Chen Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51692 Cc: 51692@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, David, Zhiwei, Yuri, and Lars. On Mon, Nov 08, 2021 at 13:00:06 -0600, David Koppelman wrote: > Load the attached file into a buffer: > ./src/emacs --no-init d.cc > Emacs will use 100% CPU on a core while the buffer is visible. CPU usage > goes to normal when switching to another buffer. The attached file is a > reduced version of a much larger file. (The larger file experiences the > high CPU usage only while a certain portion of the code is visible.) Yes, there is a bug here. CC Mode is expected to use a high amount of CPU time (but not 100%) for a few seconds after starting C (etc.) Mode, or for a few minutes after starting Emacs when there's a desktop with a lot of CC Mode files in it. However, with C++ files (and likely Java files, too), a problem with templates caused this 100% usage. I'm hoping the following patch will fix it. Could you (plural) please apply this patch to the Emacs master branch, byte compile the two amended files, then load the fixed CC Mode into your Emacs. Then please try it out with your real files. (If anybody wants any help with the patching or byte compiling, feel free to send me personal email.) Then please report back to the bug list confirming that the bug is fixed, or telling me what's still not right. Thank you! diff -r 05fd00cb5937 cc-engine.el --- a/cc-engine.el Sat Oct 30 15:57:26 2021 +0000 +++ b/cc-engine.el Thu Nov 11 18:47:47 2021 +0000 @@ -6838,6 +6838,13 @@ (defvar c-found-types nil) (make-variable-buffer-local 'c-found-types) +;; Dynamically bound variable that instructs `c-forward-type' to +;; record the ranges of types that only are found. Behaves otherwise +;; like `c-record-type-identifiers'. Also when this variable is non-nil, +;; `c-fontify-new-found-type' doesn't get called (yet) for the purported +;; type. +(defvar c-record-found-types nil) + (defsubst c-clear-found-types () ;; Clears `c-found-types'. (setq c-found-types @@ -6851,7 +6858,10 @@ (let ((type (c-syntactic-content from to c-recognize-<>-arglists))) (unless (gethash type c-found-types) (puthash type t c-found-types) - (when (and (eq (string-match c-symbol-key type) 0) + (when (and (not c-record-found-types) ; Only call `c-fontify-new-fount-type' + ; when we haven't "bound" c-found-types + ; to itself in c-forward-<>-arglist. + (eq (string-match c-symbol-key type) 0) (eq (match-end 0) (length type))) (c-fontify-new-found-type type))))) @@ -8248,11 +8258,6 @@ (setq c-record-ref-identifiers (cons range c-record-ref-identifiers)))))) -;; Dynamically bound variable that instructs `c-forward-type' to -;; record the ranges of types that only are found. Behaves otherwise -;; like `c-record-type-identifiers'. -(defvar c-record-found-types nil) - (defmacro c-forward-keyword-prefixed-id (type) ;; Used internally in `c-forward-keyword-clause' to move forward ;; over a type (if TYPE is 'type) or a name (otherwise) which @@ -8480,6 +8485,11 @@ (c-forward-<>-arglist-recur all-types))) (progn (when (consp c-record-found-types) + (let ((cur c-record-found-types)) + (while (consp (car-safe cur)) + (c-fontify-new-found-type + (buffer-substring-no-properties (caar cur) (cdar cur))) + (setq cur (cdr cur)))) (setq c-record-type-identifiers ;; `nconc' doesn't mind that the tail of ;; `c-record-found-types' is t. @@ -9203,6 +9213,12 @@ (when (and (eq res t) (consp c-record-found-types)) + ;; Cause the confirmed types to get fontified. + (let ((cur c-record-found-types)) + (while (consp (car-safe cur)) + (c-fontify-new-found-type + (buffer-substring-no-properties (caar cur) (cdar cur))) + (setq cur (cdr cur)))) ;; Merge in the ranges of any types found by the second ;; `c-forward-type'. (setq c-record-type-identifiers diff -r 05fd00cb5937 cc-fonts.el --- a/cc-fonts.el Sat Oct 30 15:57:26 2021 +0000 +++ b/cc-fonts.el Thu Nov 11 18:47:47 2021 +0000 @@ -105,6 +105,7 @@ (cc-bytecomp-defun c-font-lock-objc-method) (cc-bytecomp-defun c-font-lock-invalid-string) (cc-bytecomp-defun c-before-context-fl-expand-region) +(cc-bytecomp-defun c-font-lock-fontify-region) ;; Note that font-lock in XEmacs doesn't expand face names as @@ -2431,6 +2432,7 @@ (defun c-force-redisplay (start end) ;; Force redisplay immediately. This assumes `font-lock-support-mode' is ;; 'jit-lock-mode. Set the variable `c-re-redisplay-timer' to nil. + (save-excursion (c-font-lock-fontify-region start end)) (jit-lock-force-redisplay (copy-marker start) (copy-marker end)) (setq c-re-redisplay-timer nil)) @@ -2458,7 +2460,6 @@ (dolist (win-boundary window-boundaries) (when (and (< (match-beginning 0) (cdr win-boundary)) (> (match-end 0) (car win-boundary)) - (c-get-char-property (match-beginning 0) 'fontified) (not c-re-redisplay-timer)) (setq c-re-redisplay-timer (run-with-timer 0 nil #'c-force-redisplay -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 11 15:14:00 2021 Received: (at 51692) by debbugs.gnu.org; 11 Nov 2021 20:14:00 +0000 Received: from localhost ([127.0.0.1]:42386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlGSN-0002pA-LE for submit@debbugs.gnu.org; Thu, 11 Nov 2021 15:14:00 -0500 Received: from relay.lsu.edu ([130.39.6.46]:54804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlGSM-0002ou-1l for 51692@debbugs.gnu.org; Thu, 11 Nov 2021 15:13:58 -0500 Received: from cyc.ece.lsu.edu (cyc.ece.lsu.edu [96.125.115.182]) by relay.lsu.edu (Postfix) with ESMTPS id E85BE2198B30; Thu, 11 Nov 2021 14:13:48 -0600 (CST) From: David Koppelman To: Alan Mackenzie Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? References: Date: Thu, 11 Nov 2021 14:13:48 -0600 In-Reply-To: (Alan Mackenzie's message of "Thu, 11 Nov 2021 20:00:43 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51692 Cc: Yuri D'Elia , Lars Ingebrigtsen , Zhiwei Chen , 51692@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I applied the patch and it fixes the problem! I applied the patch to the checkout on which I reported the problem (I didn't try to update). Also, I tested both on the reduced testcase and the original file, on both there was no suspiciously high CPU usage. Thank you! Alan Mackenzie writes: > Hello, David, Zhiwei, Yuri, and Lars. > > On Mon, Nov 08, 2021 at 13:00:06 -0600, David Koppelman wrote: > >> Load the attached file into a buffer: > >> ./src/emacs --no-init d.cc > >> Emacs will use 100% CPU on a core while the buffer is visible. CPU usage >> goes to normal when switching to another buffer. The attached file is a >> reduced version of a much larger file. (The larger file experiences the >> high CPU usage only while a certain portion of the code is visible.) > > Yes, there is a bug here. CC Mode is expected to use a high amount of > CPU time (but not 100%) for a few seconds after starting C (etc.) Mode, > or for a few minutes after starting Emacs when there's a desktop with a > lot of CC Mode files in it. > > However, with C++ files (and likely Java files, too), a problem with > templates caused this 100% usage. > > I'm hoping the following patch will fix it. Could you (plural) please > apply this patch to the Emacs master branch, byte compile the two > amended files, then load the fixed CC Mode into your Emacs. Then please > try it out with your real files. (If anybody wants any help with the > patching or byte compiling, feel free to send me personal email.) > > Then please report back to the bug list confirming that the bug is > fixed, or telling me what's still not right. > > Thank you! > > > > diff -r 05fd00cb5937 cc-engine.el > --- a/cc-engine.el Sat Oct 30 15:57:26 2021 +0000 > +++ b/cc-engine.el Thu Nov 11 18:47:47 2021 +0000 > @@ -6838,6 +6838,13 @@ > (defvar c-found-types nil) > (make-variable-buffer-local 'c-found-types) > > +;; Dynamically bound variable that instructs `c-forward-type' to > +;; record the ranges of types that only are found. Behaves otherwise > +;; like `c-record-type-identifiers'. Also when this variable is non-nil, > +;; `c-fontify-new-found-type' doesn't get called (yet) for the purported > +;; type. > +(defvar c-record-found-types nil) > + > (defsubst c-clear-found-types () > ;; Clears `c-found-types'. > (setq c-found-types > @@ -6851,7 +6858,10 @@ > (let ((type (c-syntactic-content from to c-recognize-<>-arglists))) > (unless (gethash type c-found-types) > (puthash type t c-found-types) > - (when (and (eq (string-match c-symbol-key type) 0) > + (when (and (not c-record-found-types) ; Only call `c-fontify-new-fount-type' > + ; when we haven't "bound" c-found-types > + ; to itself in c-forward-<>-arglist. > + (eq (string-match c-symbol-key type) 0) > (eq (match-end 0) (length type))) > (c-fontify-new-found-type type))))) > > @@ -8248,11 +8258,6 @@ > (setq c-record-ref-identifiers > (cons range c-record-ref-identifiers)))))) > > -;; Dynamically bound variable that instructs `c-forward-type' to > -;; record the ranges of types that only are found. Behaves otherwise > -;; like `c-record-type-identifiers'. > -(defvar c-record-found-types nil) > - > (defmacro c-forward-keyword-prefixed-id (type) > ;; Used internally in `c-forward-keyword-clause' to move forward > ;; over a type (if TYPE is 'type) or a name (otherwise) which > @@ -8480,6 +8485,11 @@ > (c-forward-<>-arglist-recur all-types))) > (progn > (when (consp c-record-found-types) > + (let ((cur c-record-found-types)) > + (while (consp (car-safe cur)) > + (c-fontify-new-found-type > + (buffer-substring-no-properties (caar cur) (cdar cur))) > + (setq cur (cdr cur)))) > (setq c-record-type-identifiers > ;; `nconc' doesn't mind that the tail of > ;; `c-record-found-types' is t. > @@ -9203,6 +9213,12 @@ > > (when (and (eq res t) > (consp c-record-found-types)) > + ;; Cause the confirmed types to get fontified. > + (let ((cur c-record-found-types)) > + (while (consp (car-safe cur)) > + (c-fontify-new-found-type > + (buffer-substring-no-properties (caar cur) (cdar cur))) > + (setq cur (cdr cur)))) > ;; Merge in the ranges of any types found by the second > ;; `c-forward-type'. > (setq c-record-type-identifiers > diff -r 05fd00cb5937 cc-fonts.el > --- a/cc-fonts.el Sat Oct 30 15:57:26 2021 +0000 > +++ b/cc-fonts.el Thu Nov 11 18:47:47 2021 +0000 > @@ -105,6 +105,7 @@ > (cc-bytecomp-defun c-font-lock-objc-method) > (cc-bytecomp-defun c-font-lock-invalid-string) > (cc-bytecomp-defun c-before-context-fl-expand-region) > +(cc-bytecomp-defun c-font-lock-fontify-region) > > > ;; Note that font-lock in XEmacs doesn't expand face names as > @@ -2431,6 +2432,7 @@ > (defun c-force-redisplay (start end) > ;; Force redisplay immediately. This assumes `font-lock-support-mode' is > ;; 'jit-lock-mode. Set the variable `c-re-redisplay-timer' to nil. > + (save-excursion (c-font-lock-fontify-region start end)) > (jit-lock-force-redisplay (copy-marker start) (copy-marker end)) > (setq c-re-redisplay-timer nil)) > > @@ -2458,7 +2460,6 @@ > (dolist (win-boundary window-boundaries) > (when (and (< (match-beginning 0) (cdr win-boundary)) > (> (match-end 0) (car win-boundary)) > - (c-get-char-property (match-beginning 0) 'fontified) > (not c-re-redisplay-timer)) > (setq c-re-redisplay-timer > (run-with-timer 0 nil #'c-force-redisplay From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 12 04:54:51 2021 Received: (at 51692) by debbugs.gnu.org; 12 Nov 2021 09:54:51 +0000 Received: from localhost ([127.0.0.1]:43493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlTGl-0000Qb-Jw for submit@debbugs.gnu.org; Fri, 12 Nov 2021 04:54:51 -0500 Received: from erc.thregr.org ([46.43.2.63]:45740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlTGj-0000QS-Hy for 51692@debbugs.gnu.org; Fri, 12 Nov 2021 04:54:50 -0500 Received: from [109.52.232.92] (helo=localhost) by erc.thregr.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1mlTGY-000EYZ-SG (envelope-from ); Fri, 12 Nov 2021 10:54:39 +0100 References: User-agent: mu4e 1.7.4; emacs 29.0.50 From: Yuri D'Elia To: Alan Mackenzie Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? Date: Fri, 12 Nov 2021 10:47:46 +0100 In-reply-to: Message-ID: <874k8hpulf.fsf@wavexx.thregr.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51692 Cc: 51692@debbugs.gnu.org, Lars Ingebrigtsen , David Koppelman , Zhiwei Chen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Nov 11 2021, Alan Mackenzie wrote: > Yes, there is a bug here. CC Mode is expected to use a high amount of > CPU time (but not 100%) for a few seconds after starting C (etc.) Mode, > or for a few minutes after starting Emacs when there's a desktop with a > lot of CC Mode files in it. > > However, with C++ files (and likely Java files, too), a problem with > templates caused this 100% usage. High-burst is not a problem, however I have a related question. Is it normal that repeated C-g didn't abort? There's nothing that seemed to work for me except waiting, which means that with a few scrolling moves queued I just ended up killing emacs. I didn't test if there was a difference between JIT/no-JIT versions (should there ever be in terms of quitting behavior?) > Then please report back to the bug list confirming that the bug is > fixed, or telling me what's still not right. Tested in both the small test I posted and the full source file I was working with. Applied on master. Seems to be working perfectly now. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 12 07:07:12 2021 Received: (at 51692) by debbugs.gnu.org; 12 Nov 2021 12:07:12 +0000 Received: from localhost ([127.0.0.1]:43646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlVKq-00046i-4i for submit@debbugs.gnu.org; Fri, 12 Nov 2021 07:07:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlVKk-00046A-Df for 51692@debbugs.gnu.org; Fri, 12 Nov 2021 07:07:10 -0500 Received: from [2001:470:142:3::e] (port=55582 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlVKc-0005hL-Kl; Fri, 12 Nov 2021 07:06:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dZXpehf98zWRHndnPXHU94IvHnzSYg9Eo/1FJv7keY0=; b=sAi/1U3xmpCf kGisgZ8Y8SEcno1OaP1/c1jxrjwT9F8EZcLQDUPoFWwfsk2/LkEoBdzEDWdm2Nxo6YzSK8mZUwl3u lIahRfZBwiELhad5RHMEOs5KuFE26rNJVRUkEAtu6/gH0hJFMjwQYFeV2rQR2baBeYMkqCIFhNNyM +udSxKimEa0CvSvKkggF68phc/V8r6HvTSy2fd1vLkAJJ/GYwl0oMkotWt78cSXuRXiThnSEFWb3N 8cavSsSKbmQ5yVxCwV5QdgvlSBqk1ji++PhfswGINpcdbB1JdeuP7QvkR3Z3MtC+PagH+QRdKJ8W2 OJ66QPr1kkllUEhB+vzEeg==; Received: from [87.69.77.57] (port=3774 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlVKc-0008KU-AX; Fri, 12 Nov 2021 07:06:58 -0500 Date: Fri, 12 Nov 2021 14:06:39 +0200 Message-Id: <838rxtzigg.fsf@gnu.org> From: Eli Zaretskii To: Yuri D'Elia In-Reply-To: <874k8hpulf.fsf@wavexx.thregr.org> (message from Yuri D'Elia on Fri, 12 Nov 2021 10:47:46 +0100) Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? References: <874k8hpulf.fsf@wavexx.thregr.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 51692 Cc: larsi@gnus.org, acm@muc.de, 51692@debbugs.gnu.org, condy0919@gmail.com, koppel@ece.lsu.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuri D'Elia > Date: Fri, 12 Nov 2021 10:47:46 +0100 > Cc: 51692@debbugs.gnu.org, David Koppelman , > Zhiwei Chen , Lars Ingebrigtsen > > On Thu, Nov 11 2021, Alan Mackenzie wrote: > > Yes, there is a bug here. CC Mode is expected to use a high amount of > > CPU time (but not 100%) for a few seconds after starting C (etc.) Mode, > > or for a few minutes after starting Emacs when there's a desktop with a > > lot of CC Mode files in it. > > > > However, with C++ files (and likely Java files, too), a problem with > > templates caused this 100% usage. > > High-burst is not a problem, however I have a related question. Is it > normal that repeated C-g didn't abort? What do you expect C-g to do when Emacs is in the middle of redisplay? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 12 14:08:56 2021 Received: (at 51692) by debbugs.gnu.org; 12 Nov 2021 19:08:56 +0000 Received: from localhost ([127.0.0.1]:45973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlbuy-0002vU-F8 for submit@debbugs.gnu.org; Fri, 12 Nov 2021 14:08:56 -0500 Received: from colin.muc.de ([193.149.48.1]:45451 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mlbuv-0002vB-BY for 51692@debbugs.gnu.org; Fri, 12 Nov 2021 14:08:55 -0500 Received: (qmail 354 invoked by uid 3782); 12 Nov 2021 19:08:46 -0000 Received: from acm.muc.de (p4fe15acc.dip0.t-ipconnect.de [79.225.90.204]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 12 Nov 2021 20:08:46 +0100 Received: (qmail 31883 invoked by uid 1000); 12 Nov 2021 19:08:43 -0000 Date: Fri, 12 Nov 2021 19:08:43 +0000 To: Yuri D'Elia Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? Message-ID: References: <874k8hpulf.fsf@wavexx.thregr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874k8hpulf.fsf@wavexx.thregr.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51692 Cc: 51692@debbugs.gnu.org, Lars Ingebrigtsen , David Koppelman , Zhiwei Chen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Yuri. On Fri, Nov 12, 2021 at 10:47:46 +0100, Yuri D'Elia wrote: > On Thu, Nov 11 2021, Alan Mackenzie wrote: > > Yes, there is a bug here. CC Mode is expected to use a high amount of > > CPU time (but not 100%) for a few seconds after starting C (etc.) Mode, > > or for a few minutes after starting Emacs when there's a desktop with a > > lot of CC Mode files in it. > > However, with C++ files (and likely Java files, too), a problem with > > templates caused this 100% usage. > High-burst is not a problem, however I have a related question. Is it > normal that repeated C-g didn't abort? No. In this particular scenario, though, the 100% CPU usage was happening in a timer function, so your C-g would just abort the foreground function, i.e. nothing. At least in this situation Emacs wasn't completely frozen, since foreground processing took priority over the background fontification. > There's nothing that seemed to work for me except waiting, which means > that with a few scrolling moves queued I just ended up killing emacs. Ah. Sorry. > I didn't test if there was a difference between JIT/no-JIT versions > (should there ever be in terms of quitting behavior?) I don't know that. But jit is pretty much universal now, apart from for testing purposes by developers. > > Then please report back to the bug list confirming that the bug is > > fixed, or telling me what's still not right. > Tested in both the small test I posted and the full source file I was > working with. Applied on master. Seems to be working perfectly now. Thanks! That's good to hear. I'll just give Zhiwei Chen a little time to reply, and assuming (s)he doesn't find problems, I'll commit the fix. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 04:24:34 2021 Received: (at 51692) by debbugs.gnu.org; 13 Nov 2021 09:24:34 +0000 Received: from localhost ([127.0.0.1]:46480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlpH0-0008Um-J3 for submit@debbugs.gnu.org; Sat, 13 Nov 2021 04:24:34 -0500 Received: from mail-pl1-f170.google.com ([209.85.214.170]:37677) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlpGy-0008UV-Gt for 51692@debbugs.gnu.org; Sat, 13 Nov 2021 04:24:33 -0500 Received: by mail-pl1-f170.google.com with SMTP id n8so10369902plf.4 for <51692@debbugs.gnu.org>; Sat, 13 Nov 2021 01:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=d2Ln68W8Zx5ptgpxg00vLejl8RWC1XXBk4R12FGp+RE=; b=edNfeyQkEWBa1Mgq7OkoV5vL2JNLuhNObDhTLLbZLMnCfhdbwOCPgZNsFhPG273j0r pAPM0W+XofH7i7F1UJRx3wX9IZCdX3MpIesUBHlvAR9uJxN1Mu0n4eUFjpyncxVBLeHN 7nYTn/QfQ/nmGRzM1RmxcYZo1RlxvunlG+ejtmPhAUmTaiM8c0vLOCZDhFAVsRMMj253 LPXlRCOrDYRQ03mivlE/FcIu9H8ah3UPDQuTWT2RxQtW0WdOs4t710rIg7893fQBxNd6 1ftB3uS8N18kfRHkPeS7B8KFu08oPSiyUJUg50fkCBxI8W866Q+jdLTra48yWIqx5cXI xa+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=d2Ln68W8Zx5ptgpxg00vLejl8RWC1XXBk4R12FGp+RE=; b=czNoMKcy/LWyHL0RA4UI9cNHvhRlkI6as4M1JWMMQkVQ9AvjVRLURiTMyF8U6gy8HQ guqVmwQC619biFKqWtMB0acMs8lFE7zAFDuqNohZAKxgXxNryo+sQff7uaSiqVMKlZi/ +SDgExBO7fh6CW8ofR5FRMq6is8CYmp8wCP3SBuw59yLqRT6d6LhaZoxSn6SfEyeW87W V5OTaHLzEREcmFyd2255llAb4VLJIX6P8E8HqNNLyDHYHEo8Ut5BM0Te1y5nNGQ5E92c V/jJNgA5vAOPAKcFrjoVgaHZBrFgQpiuqzWKZC1cMDQ23jBba9Y3zUeCGZfMOOqgbjhh RYRw== X-Gm-Message-State: AOAM531vJuQsWexDVehuStPqJcyCgeCwz7OXkdlFiTIBCjN1YOeLD9c2 DmbW9QAxgAZZLWMITLPoZQo= X-Google-Smtp-Source: ABdhPJxY5es6pS8RlxtnD25tiu6LZOjzB/l5fBimhXva5yetk8KegzHiNBz+M4feWQSIrcutfqfKlQ== X-Received: by 2002:a17:902:be06:b0:142:5a21:9e8a with SMTP id r6-20020a170902be0600b001425a219e8amr15660479pls.17.1636795466774; Sat, 13 Nov 2021 01:24:26 -0800 (PST) Received: from Youmu (192.69.92.236.16clouds.com. [192.69.92.236]) by smtp.gmail.com with ESMTPSA id s3sm7354783pjk.41.2021.11.13.01.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 01:24:26 -0800 (PST) From: Zhiwei Chen To: Alan Mackenzie Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? References: <874k8hpulf.fsf@wavexx.thregr.org> Date: Sat, 13 Nov 2021 17:24:22 +0800 In-Reply-To: (Alan Mackenzie's message of "Fri, 12 Nov 2021 19:08:43 +0000") Message-ID: <87zgq8o1bt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 51692 Cc: Yuri D'Elia , Lars Ingebrigtsen , David Koppelman , 51692@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Alan Mackenzie writes: > Thanks! That's good to hear. I'll just give Zhiwei Chen a little time > to reply, and assuming (s)he doesn't find problems, I'll commit the fix. It solves the issue after applied the patch on Emacs trunk. Thanks. -- Zhiwei Chen From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 07:10:20 2021 Received: (at 51692-done) by debbugs.gnu.org; 13 Nov 2021 12:10:21 +0000 Received: from localhost ([127.0.0.1]:46673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mlrrQ-0004vV-Ov for submit@debbugs.gnu.org; Sat, 13 Nov 2021 07:10:20 -0500 Received: from colin.muc.de ([193.149.48.1]:16604 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mlrrL-0004v5-Aq for 51692-done@debbugs.gnu.org; Sat, 13 Nov 2021 07:10:19 -0500 Received: (qmail 87836 invoked by uid 3782); 13 Nov 2021 12:10:08 -0000 Received: from acm.muc.de (p4fe15fc7.dip0.t-ipconnect.de [79.225.95.199]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 13 Nov 2021 13:10:08 +0100 Received: (qmail 24772 invoked by uid 1000); 13 Nov 2021 12:10:07 -0000 Date: Sat, 13 Nov 2021 12:10:07 +0000 To: Zhiwei Chen Subject: Re: bug#51692: 29.0.50; High CPU in c++ mode. Type finder? Message-ID: References: <874k8hpulf.fsf@wavexx.thregr.org> <87zgq8o1bt.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgq8o1bt.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51692-done Cc: Yuri D'Elia , Lars Ingebrigtsen , David Koppelman , 51692-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Zhiwei, David, Yuri, and Lars. On Sat, Nov 13, 2021 at 17:24:22 +0800, Zhiwei Chen wrote: > Alan Mackenzie writes: > > Thanks! That's good to hear. I'll just give Zhiwei Chen a little time > > to reply, and assuming (s)he doesn't find problems, I'll commit the fix. > It solves the issue after applied the patch on Emacs trunk. Thanks. Thanks to everybody for the testing. I have now committed the fix to the master branch, and am closing the bug with this post. > -- > Zhiwei Chen -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 11 Dec 2021 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator