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

Previous Next

Package: emacs;

Reported by: Chris Hecker <checker <at> d6.com>

Date: Sat, 5 Nov 2022 02:49:01 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log

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

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: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 11:28:10 +0200

> Date: Sat, 5 Nov 2022 08:50:33 +0100
> Cc: checker <at> d6.com, 59038 <at> debbugs.gnu.org, acm <at> muc.de
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> 
> On 05.11.22 08:01, Eli Zaretskii wrote:
> > What is reproducible, exactly?  
> 
> I don't understand.  The infinite loop is reproducible, "pegging one
> core" as he expressed it, using up one CPU core.

Not here, it isn't.

> > Visiting the file is almost
> > instantaneous here, in Emacs 29.  What did you do to get Emacs into an
> > infloop?
> 
> Maybe I switched applications with Cmd-TAB, or something else triggering
> redisplay.  Do a M-x or C-l.

No, that doesn't trigger it.  Only M-> does.

> > 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.
> 
> I think no-one expects that.  The bug is the uninterruptable loop or 
> whatever causes it.

It's nice to have that fixed, if it isn't too complex, but in general
visiting such a file as C file is not a reasonable thing to do.
This bug report was last modified 2 years and 198 days ago.

Previous Next

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