GNU bug report logs - #59038
loading this base64 file makes emacs -Q 28.2 peg a core infinitely

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Phil Sainty <psainty <at> orcon.net.nz>
Cc: 59038 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>,
 Eli Zaretskii <eliz <at> gnu.org>, checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 6 Nov 2022 13:54:47 +0000

Hello, Gerd and Phil.

On Sun, Nov 06, 2022 at 06:20:17 +0100, Gerd Möllmann wrote:
> Phil Sainty <psainty <at> orcon.net.nz> writes:

> > On 2022-11-06 12:41, Gregory Heytings wrote:
> >> That file opens just fine in other modes

> > It also opens fine in c-mode, with global-font-lock-mode disabled.

> >> Note that this bug has nothing to do with long lines.

> > I imagine that the font-lock issue is related to the line being
> > in excess of 21,000 chars (but general redisplay obviously doesn't
> > have problems with lines this 'small').

> > Reduced to 10,208 chars that file opens instantly under emacs -Q
> > in c-mode with font-lock enabled; but at 10,209 chars it hangs
> > Emacs (I killed it after waiting 4 minutes).

> It could also be that this is not something with the position of size,
> but with what's there at or around that position.  Just an idea.

I've identified the place in the code where it's looping, namely in the
defun c-brace-stack-at.

Gerd's Lisp backtraces earlier on in the thread were extremely helpful,
as was Phil's identification of the minimum size of buffer needed to
trigger the infinite loop.

I don't yet know why that function is looping, or why it does so only
from a certain length of buffer, but I'm working on it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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