bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infin


From: Eli Zaretskii
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@debbugs.gnu.org, Alan Mackenzie <acm@muc.de>
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 05 Nov 2022 06:12:37 +0100
> 
> "Chris Hecker" <checker@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]