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

[Message part 1 (text/plain, inline)]

> It's a single 21,728-character line.

Yeah?  This isn’t 1970.  I have 32gb of ram and a 12 core cpu.   It’s a
bug.  It should either parse the file (instantly, it’s 27kb) or it should
at least stop after a few ms and tell me it’s lame and needs me to switch
manually to another mode.  I mean, given the 28.2 user experience, there is
no opportunity to switch to fundamental mode because emacs was hosed.  I
don’t even think ctrl-g worked for me.

Chris



On Sat, Nov 5, 2022 at 00:50 Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:

> 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.
>
> > 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.
>
> > 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.
>

[Message part 2 (text/html, inline)]

Previous Next

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