From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#48839: 28.0.50; Emacs freezes and takes 100% CPU with C-h v l Date: Sat, 05 Jun 2021 09:27:39 +0300 Message-ID: <83bl8kltb8.fsf@gnu.org> References: <87czt16ydq.fsf@fastmail.fm> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mail@daniel-mendler.de, 48839@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 05 08:28:10 2021 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 1lpPmz-0009Mh-N5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Jun 2021 08:28:09 +0200 Original-Received: from localhost ([::1]:41194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpPmx-0006gE-QT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Jun 2021 02:28:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpPms-0006g5-4j for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 02:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36685) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpPmr-0005QU-Ug for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 02:28:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lpPmr-0006Bx-LP for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 02:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 06:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48839 X-GNU-PR-Package: emacs Original-Received: via spool by 48839-submit@debbugs.gnu.org id=B48839.162287447823793 (code B ref 48839); Sat, 05 Jun 2021 06:28:01 +0000 Original-Received: (at 48839) by debbugs.gnu.org; 5 Jun 2021 06:27:58 +0000 Original-Received: from localhost ([127.0.0.1]:48231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpPmk-0006Bb-B5 for submit@debbugs.gnu.org; Sat, 05 Jun 2021 02:27:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpPmf-0006BJ-Gn for 48839@debbugs.gnu.org; Sat, 05 Jun 2021 02:27:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40516) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpPmZ-0005Bw-Fx; Sat, 05 Jun 2021 02:27:43 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3446 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 1lpPmZ-0006e6-3F; Sat, 05 Jun 2021 02:27:43 -0400 In-Reply-To: <87czt16ydq.fsf@fastmail.fm> (message from Tassilo Horn on Sat, 05 Jun 2021 00:01:59 +0200) 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" Xref: news.gmane.io gmane.emacs.bugs:208044 Archived-At: > From: Tassilo Horn > Date: Sat, 05 Jun 2021 00:01:59 +0200 > > Looking at the marginalia code, I can see no evil, and indeed I can > un-marginaliarize the sample to > > (let ((print-escape-newlines t) > (print-escape-control-characters t) > (print-escape-multibyte t)) > (string-width (prin1-to-string load-history))) > > which freezes my emacs in the same way. Concretely, `prin1-to-string' > finishes and returns a 1.3 MB string and then `string-width' will run > indefinitely on that. string-width on the current master has a design bug, which causes it to be VERY slow on very long strings, if those strings don't include newlines or similar characters. I'm working on fixing that design bug, but meanwhile: why does marginalia need to compute the width of such very long strings? that sounds like a design bug in marginalia. The simplest fix is not to compute string-width of any string whose length is greater than, say, 300 characters. Does that help in this case?