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: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 59038 <at> debbugs.gnu.org, acm <at> muc.de, checker <at> d6.com
Subject: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely
Date: Sat, 05 Nov 2022 09:01:31 +0200

> Cc: 59038 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sat, 05 Nov 2022 06:12:37 +0100
> 
> "Chris Hecker" <checker <at> d6.com> writes:
> 
> > gunzip this file (it's a c header file base64 encoded from
> > googlesource.com) to Looper.h and load it with 28.2 emacs -Q and it'll
> > infinite loop pegging one core.
> 
> Thanks for the report, Chris.
> 
> This is reproducible with master fd3f51b7c3a6649ee3db12d33b056b1afdbfa7e9.

What is reproducible, exactly?  Visiting the file is almost
instantaneous here, in Emacs 29.  What did you do to get Emacs into an
infloop?

> It might be related to cc-mode, so I've CC'd Alan.  Emacs goes into an
> infloop while font-locking the encoded .h file.  Below are some Lisp
> backtraces from interrupting the loop:

I don't think it's interesting.  In its encoded form, this is not a C
file, this is just a long bunch of random characters.  To decode it,
one should switch to Fundamental mode, then decode it, then switch
back to C mode.

It is IMO unreasonable to expect CC Mode to do something sensible with
random sequence of characters that don't resemble C in any way.

Previous Next

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