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

Previous Next

Full log

View this message in rfc822 format

From: "Chris Hecker" <checker <at> d6.com>
To: "Alan Mackenzie" <acm <at> muc.de>, "Eli Zaretskii" <eliz <at> gnu.org>
Cc: psainty <at> orcon.net.nz, gerd.moellmann <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>, 59038 <at> debbugs.gnu.org
Subject: bug#59038: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely
Date: Sun, 06 Nov 2022 19:46:01 +0000

Yay!  Go team!

Thanks,
Chris

------ Original Message ------
From: "Alan Mackenzie" <acm <at> muc.de>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: "Gregory Heytings" <gregory <at> heytings.org>; psainty <at> orcon.net.nz; 
gerd.moellmann <at> gmail.com; 59038 <at> debbugs.gnu.org; checker <at> d6.com
Sent: 2022-11-06 08:34:57
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg 
a core infinitely

>Hello, Eli.
>
>On Sun, Nov 06, 2022 at 15:52:33 +0200, Eli Zaretskii wrote:
>>  > Date: Sun, 06 Nov 2022 09:18:23 +0000
>>  > From: Gregory Heytings <gregory <at> heytings.org>
>>  > cc: Eli Zaretskii <eliz <at> gnu.org>,
>>  >     Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>>  >     59038 <at> debbugs.gnu.org, checker <at> d6.com, acm <at> muc.de
>
>
>>  > >> That file opens just fine in other modes
>
>>  > > It also opens fine in c-mode, with global-font-lock-mode disabled.
>
>
>>  > Indeed, obviously it's a c-mode font-locking related bug.
>
>>  > >> 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).
>
>
>>  > Interesting, thanks for the bisection!
>
>>  It's an infloop in c-brace-stack-at.
>
>>  What happens is that c-brace-stack-at calls c-update-brace-stack with
>>  arguments: (nil 1) 8160 13160.  c-update-brace-stack then calls
>>  c-syntactic-re-search-forward, which finds nothing interesting and
>>  returns with point at 13160, but then c-update-brace-stack calls
>>  c-beginning-of-current-token, which returns point back to 8160.  And
>>  it goes on and on and on...
>
>Thanks for the debugging.
>
>>  Alan, what can be done with this?
>
>This:
>
>
>diff -r 53717eda724c cc-engine.el
>--- a/cc-engine.el	Sat Oct 29 09:42:47 2022 +0000
>+++ b/cc-engine.el	Sun Nov 06 16:26:09 2022 +0000
>@@ -6177,9 +6177,10 @@
>  	    (setq s (cdr s))))
>  	 ((c-keyword-member kwd-sym 'c-flat-decl-block-kwds)
>  	  (push 0 s))))
>-      ;; The failing `c-syntactic-re-search-forward' may have left us in the
>-      ;; middle of a token, which might be a significant token.  Fix this!
>-      (c-beginning-of-current-token)
>+      (when (> prev-match-pos 1)      ; Has the search matched at least once?
>+	;; The failing `c-syntactic-re-search-forward' may have left us in the
>+	;; middle of a token, which might be a significant token.  Fix this!
>+	(c-beginning-of-current-token))
>        (cons (point)
>  	    (cons bound-<> s)))))
>
>
>--
>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.