GNU bug report logs - #48839
28.0.50; Emacs freezes and takes 100% CPU with C-h v l

Previous Next

Full log

Message #8 received at 48839 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tassilo Horn <thorn <at> fastmail.fm>
Cc: mail <at> daniel-mendler.de, 48839 <at> debbugs.gnu.org
Subject: Re: 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

> From: Tassilo Horn <thorn <at> fastmail.fm>
> 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?

Previous Next

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