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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59038 in the body.
You can then email your comments to 59038 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Chris Hecker" <checker <at> d6.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: loading this base64 file makes emacs -Q 28.2 peg a core infinitely
Date: Sat, 05 Nov 2022 02:48:42 +0000

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

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.

Expected behavior:  load the file, and let me base64-decode it.

It's a long line, but not _that_ long.

If you don't want my gz file, this url will get you the same file:

https://android.googlesource.com/platform/system/core/+/android-5.0.0_r2/include/utils/Looper.h?format=TEXT

Chris

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

[Looper.h.gz (application/x-gzip, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: "Chris Hecker" <checker <at> d6.com>
Cc: 59038 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
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.

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:

(unsigned char *) data = 0x0000000100280ecb "skip-syntax-backward"
(unsigned char *) data = 0x000000010328e580 "c-beginning-of-current-token"
(unsigned char *) data = 0x000000010328f9e0 "c-update-brace-stack"
(unsigned char *) data = 0x000000010328fb40 "c-brace-stack-at"
(unsigned char *) data = 0x000000010328fb60 "c-bs-at-toplevel-p"
(unsigned char *) data = 0x000000010328fcd0 "c-find-decl-spots"
(unsigned char *) data = 0x00000001032c96d8 "c-font-lock-declarations"
(unsigned char *) data = 0x0000000104b79b52 "font-lock-fontify-keywords-region"
(unsigned char *) data = 0x0000000104b7f7d5 "font-lock-default-fontify-region"
(unsigned char *) data = 0x00000001032fc2f8 "c-font-lock-fontify-region"
(unsigned char *) data = 0x0000000104bcf23f "font-lock-fontify-region"
PVEC_COMPILED
(unsigned char *) data = 0x000000010027b168 "run-hook-wrapped"
(unsigned char *) data = 0x0000000104b6b2f2 "jit-lock--run-functions"
(unsigned char *) data = 0x0000000104b9887d "jit-lock-fontify-now"
(unsigned char *) data = 0x0000000104bb05ff "jit-lock-function"
(unsigned char *) data = 0x000000010027f89f "redisplay_internal (C function)"

(unsigned char *) data = 0x0000000100280f1c "parse-partial-sexp"
(unsigned char *) data = 0x000000010328f640 "c-syntactic-re-search-forward"
(unsigned char *) data = 0x000000010328f9e0 "c-update-brace-stack"
(unsigned char *) data = 0x000000010328fb40 "c-brace-stack-at"
(unsigned char *) data = 0x000000010328fb60 "c-bs-at-toplevel-p"
(unsigned char *) data = 0x000000010328fcd0 "c-find-decl-spots"
(unsigned char *) data = 0x00000001032c96d8 "c-font-lock-declarations"
(unsigned char *) data = 0x0000000104b79b52 "font-lock-fontify-keywords-region"
(unsigned char *) data = 0x0000000104b7f7d5 "font-lock-default-fontify-region"
(unsigned char *) data = 0x00000001032fc2f8 "c-font-lock-fontify-region"
(unsigned char *) data = 0x0000000104bcf23f "font-lock-fontify-region"
PVEC_COMPILED
(unsigned char *) data = 0x000000010027b168 "run-hook-wrapped"
(unsigned char *) data = 0x0000000104b6b2f2 "jit-lock--run-functions"
(unsigned char *) data = 0x0000000104b9887d "jit-lock-fontify-now"
(unsigned char *) data = 0x0000000104bb05ff "jit-lock-function"
(unsigned char *) data = 0x000000010027f89f "redisplay_internal (C function)"

(unsigned char *) data = 0x00000001002783c1 "re-search-forward"
(unsigned char *) data = 0x000000010328f640 "c-syntactic-re-search-forward"
(unsigned char *) data = 0x000000010328f9e0 "c-update-brace-stack"
(unsigned char *) data = 0x000000010328fb40 "c-brace-stack-at"
(unsigned char *) data = 0x000000010328fb60 "c-bs-at-toplevel-p"
(unsigned char *) data = 0x000000010328fcd0 "c-find-decl-spots"
(unsigned char *) data = 0x00000001032c96d8 "c-font-lock-declarations"
(unsigned char *) data = 0x0000000104b79b52 "font-lock-fontify-keywords-region"
(unsigned char *) data = 0x0000000104b7f7d5 "font-lock-default-fontify-region"
(unsigned char *) data = 0x00000001032fc2f8 "c-font-lock-fontify-region"
(unsigned char *) data = 0x0000000104bcf23f "font-lock-fontify-region"
PVEC_COMPILED
(unsigned char *) data = 0x000000010027b168 "run-hook-wrapped"
(unsigned char *) data = 0x0000000104b6b2f2 "jit-lock--run-functions"
(unsigned char *) data = 0x0000000104b9887d "jit-lock-fontify-now"
(unsigned char *) data = 0x0000000104bb05ff "jit-lock-function"
(unsigned char *) data = 0x000000010027f89f "redisplay_internal (C function)"

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Hecker <checker <at> d6.com>
Cc: 59038 <at> debbugs.gnu.org
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core
 infinitely
Date: Sat, 05 Nov 2022 08:52:55 +0200

> From: "Chris Hecker" <checker <at> d6.com>
> Date: Sat, 05 Nov 2022 02:48:42 +0000
> 
> 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.  
> 
> Expected behavior:  load the file, and let me base64-decode it.
> 
> It's a long line, but not _that_ long.

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

With Emacs 29 (from the master branch of the Emacs Git repository), I
have no trouble visiting the file.  It triggers the new long-line
optimizations feature.

So I think the problem you have is already fixed for the upcoming
Emacs 29.

Message #14 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 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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, 5 Nov 2022 08:50:33 +0100

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 #20 received at 59038 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Chris Hecker <checker <at> d6.com>
Cc: 59038 <at> debbugs.gnu.org, acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 09:45:02 +0100

Chris Hecker <checker <at> d6.com> writes:

>> It's a single 21,728-character line.
>
> Yeah?  This isn’t 1970.  I have 32gb of ram and a 12 core cpu. 

I think Eli was meaning that the size of the line should not cause
problems.  The long-lines optimizations in the coming Emacs 29 wasn't
exactly easy, and mentioining long lines is kind of a trigger ATM, I
guess :-).

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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Hecker <checker <at> d6.com>
Cc: gerd.moellmann <at> gmail.com, 59038 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 11:30:58 +0200

> From: Chris Hecker <checker <at> d6.com>
> Date: Sat, 5 Nov 2022 01:21:34 -0700
> Cc: 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
> 
> > 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.

Like I said, try Emacs 29, where this should be fixed.

I mentioned the actual length of the line FTR, not as an excuse for
unbearably slow display.

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

From: "Chris Hecker" <checker <at> d6.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 59038 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 10:39:49 +0000

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

I mentioned the actual length of the line FTR, not as an excuse for
unbearably slow display.

Ah, ok, sorry, I thought you were disagreeing that the line was not that 
long.  :)

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.

Right, but I didn't know this was what ?format=TEXT downloaded from 
googlesource.com, so if I'd had unsaved buffers I would have been 
screwed.  Luckily I didn't lose work (except having to reopen a bunch of 
files to get back to where I was).

Like I said, try Emacs 29, where this should be fixed.

I just upgraded to 28 from 26, which took a while!  :)   Anyway, I'll 
give it a shot sometime, but it sounds like you and Gerd are having 
different experiences with this file?

Chris





------ Original Message ------
From: "Eli Zaretskii" <eliz <at> gnu.org>
To: "Chris Hecker" <checker <at> d6.com>
Cc: gerd.moellmann <at> gmail.com; 59038 <at> debbugs.gnu.org; acm <at> muc.de
Sent: 2022-11-05 02:30:58
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg 
a core infinitely

>>  From: Chris Hecker <checker <at> d6.com>
>>  Date: Sat, 5 Nov 2022 01:21:34 -0700
>>  Cc: 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
>>
>>  > 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.
>
>Like I said, try Emacs 29, where this should be fixed.
>
>I mentioned the actual length of the line FTR, not as an excuse for
>unbearably slow display.

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

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Chris Hecker <checker <at> d6.com>
Cc: 59038 <at> debbugs.gnu.org
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 23:45:47 +1300

AFAIU this kind of thing is fixed for Emacs 29.

In Emacs 28 and earlier, enable global-so-long-mode in your
init file and then visiting such files will not hang Emacs.


-Phil

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

From: Po Lu <luangruo <at> yahoo.com>
To: Chris Hecker <checker <at> d6.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 19:29:39 +0800

Chris Hecker <checker <at> d6.com> writes:

> Yeah?  This isn’t 1970.

Emacs becoming unusable due to long lines has been fixed in Emacs 29.

> I have 32gb of ram and a 12 core cpu.

Physical memory and the number of processors installed does not really
matter here, unfortunately, as Emacs only uses one processor to process
your (27kb) file.

> (instantly, it’s 27kb)

Which is a lot, even in this day and age.

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

A few ms is shorter than a roundtrip to and fro the X server over my
current connection.  But:

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

All of this is no longer a problem in Emacs 29, and even if you somehow
still cause redisplay to become wedged, you can set max-redisplay-ticks
to a suitable value.

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

From: Chris Hecker <checker <at> d6.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 59038 <at> debbugs.gnu.org,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 5 Nov 2022 08:01:33 -0700

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

>> (instantly, it’s 27kb)
> Which is a lot, even in this day and age.

I don't even know what to say to this.  Literally every other editor I
tried including the immense pile that is visual studio opened this file
instantly, including ones that do syntax highlighting.

I love emacs but holy cow you need to renormalize what you think a modern
computer is capable of so your performance expectations for emacs are more
realistic.

Anyway, I’m glad it’s fixed in 29.

Chris

On Sat, Nov 5, 2022 at 04:29 Po Lu <luangruo <at> yahoo.com> wrote:

> Chris Hecker <checker <at> d6.com> writes:
>
> > Yeah?  This isn’t 1970.
>
> Emacs becoming unusable due to long lines has been fixed in Emacs 29.
>
> > I have 32gb of ram and a 12 core cpu.
>
> Physical memory and the number of processors installed does not really
> matter here, unfortunately, as Emacs only uses one processor to process
> your (27kb) file.
>
> > (instantly, it’s 27kb)
>
> Which is a lot, even in this day and age.
>
> > 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.
>
> A few ms is shorter than a roundtrip to and fro the X server over my
> current connection.  But:
>
> > 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.
>
> All of this is no longer a problem in Emacs 29, and even if you somehow
> still cause redisplay to become wedged, you can set max-redisplay-ticks
> to a suitable value.
>

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

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

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Chris Hecker <checker <at> d6.com>
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 5 Nov 2022 22:03:51 +0000

Hello, Po.

On Sat, Nov 05, 2022 at 19:29:39 +0800, Po Lu wrote:

[ .... ]

> All of this is no longer a problem in Emacs 29, and even if you somehow
> still cause redisplay to become wedged, you can set max-redisplay-ticks
> to a suitable value.

I looked that up in Emacs with C-h v.  It says it's the maximum number
of "redisplay ticks" before some aborting or other occurs.

I don't know what a redisplay tick is, and the dock string doesn't
explain it.  I've never heard of the term before.

This doc string is thus not very helpful, quite the reverse.

Maybe one of the manuals explains it.  It would be nice to have that
doc string amended to be less puzzling.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, checker <at> d6.com, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 22:27:47 +0000

>> This is reproducible with master 
>> fd3f51b7c3a6649ee3db12d33b056b1afdbfa7e9.
>
> What is reproducible, exactly?  Visiting the file is almost 
> instantaneous here, in Emacs 29.
>

Visiting the file, yes.  Try C-e, and you'll see that Emacs hangs.  At 
least it does, here.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, checker <at> d6.com, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sat, 05 Nov 2022 23:41:26 +0000

>>> This is reproducible with master 
>>> fd3f51b7c3a6649ee3db12d33b056b1afdbfa7e9.
>> 
>> What is reproducible, exactly?  Visiting the file is almost 
>> instantaneous here, in Emacs 29.
>
> Visiting the file, yes.  Try C-e, and you'll see that Emacs hangs.  At 
> least it does, here.
>

Another recipe:
emacs -Q
M-: (set-frame-width nil 100)
C-x C-f Looper.h RET

Note that this bug has nothing to do with long lines.  That file opens 
just fine in other modes (e.g. Fundamental, Elisp, Text), even with long 
line optimizations turned off.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, checker <at> d6.com,
 acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 16:58:01 +1300

On 2022-11-06 12:41, Gregory Heytings wrote:
> That file opens just fine in other modes

It also opens fine in c-mode, with global-font-lock-mode disabled.

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


-Phil

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Chris Hecker <checker <at> d6.com>
Cc: Po Lu <luangruo <at> yahoo.com>, 59038 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 06:17:26 +0100

Chris Hecker <checker <at> d6.com> writes:

> Anyway, I’m glad it’s fixed in 29.

I'm afraid it's not.  I reproduced this in master, which is 29.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 06 Nov 2022 06:18:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Your call.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 59038 <at> debbugs.gnu.org, acm <at> muc.de, Gregory Heytings <gregory <at> heytings.org>,
 Eli Zaretskii <eliz <at> gnu.org>, checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 06:20:17 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

> On 2022-11-06 12:41, Gregory Heytings wrote:
>> That file opens just fine in other modes
>
> It also opens fine in c-mode, with global-font-lock-mode disabled.
>
>> 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).

It could also be that this is not something with the position of size,
but with what's there at or around that position.  Just an idea.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: luangruo <at> yahoo.com, gerd.moellmann <at> gmail.com, 59038 <at> debbugs.gnu.org,
 checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 08:00:00 +0200

> Date: Sat, 5 Nov 2022 22:03:51 +0000
> Cc: Chris Hecker <checker <at> d6.com>,
>   Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>   59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > All of this is no longer a problem in Emacs 29, and even if you somehow
> > still cause redisplay to become wedged, you can set max-redisplay-ticks
> > to a suitable value.
> 
> I looked that up in Emacs with C-h v.  It says it's the maximum number
> of "redisplay ticks" before some aborting or other occurs.
> 
> I don't know what a redisplay tick is, and the dock string doesn't
> explain it.  I've never heard of the term before.
> 
> This doc string is thus not very helpful, quite the reverse.
> 
> Maybe one of the manuals explains it.  It would be nice to have that
> doc string amended to be less puzzling.

There's nothing to explain that can be easily explained to someone who
isn't privy to the display code internals.  What does "redisplay
ticks" tell you intuitively?  Chances are your intuition is correct.

The mechanisms behind that variable are not important, as long as our
recent measures to cope with very long lines do their job, so I see no
reason to document the ticks stuff more than it already is.  If you
are really interested, grep the sources for update_redisplay_ticks.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, checker <at> d6.com,
 acm <at> muc.de
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 09:18:23 +0000

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>, acm <at> muc.de
Cc: psainty <at> orcon.net.nz, gerd.moellmann <at> gmail.com, 59038 <at> debbugs.gnu.org,
 checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 06 Nov 2022 15:52:33 +0200

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

Alan, what can be done with this?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Phil Sainty <psainty <at> orcon.net.nz>
Cc: 59038 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>,
 Eli Zaretskii <eliz <at> gnu.org>, checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 6 Nov 2022 13:54:47 +0000

Hello, Gerd and Phil.

On Sun, Nov 06, 2022 at 06:20:17 +0100, Gerd Möllmann wrote:
> Phil Sainty <psainty <at> orcon.net.nz> writes:

> > On 2022-11-06 12:41, Gregory Heytings wrote:
> >> That file opens just fine in other modes

> > It also opens fine in c-mode, with global-font-lock-mode disabled.

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

> It could also be that this is not something with the position of size,
> but with what's there at or around that position.  Just an idea.

I've identified the place in the code where it's looping, namely in the
defun c-brace-stack-at.

Gerd's Lisp backtraces earlier on in the thread were extremely helpful,
as was Phil's identification of the minimum size of buffer needed to
trigger the infinite loop.

I don't yet know why that function is looping, or why it does so only
from a certain length of buffer, but I'm working on it.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: 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, checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Sun, 6 Nov 2022 16:34:57 +0000

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

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

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

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: psainty <at> orcon.net.nz, 59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Gregory Heytings <gregory <at> heytings.org>, checker <at> d6.com
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Mon, 07 Nov 2022 08:55:42 +0100

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

>> Alan, what can be done with this?
>
> This:

Works for me.  Thanks, Alan!

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

From: Alan Mackenzie <acm <at> muc.de>
To: Chris Hecker <checker <at> d6.com>
Cc: psainty <at> orcon.net.nz, gerd.moellmann <at> gmail.com,
 Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>,
 59038-done <at> debbugs.gnu.org
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a
 core infinitely
Date: Mon, 7 Nov 2022 12:25:29 +0000

Hello, Chris.

On Sun, Nov 06, 2022 at 19:46:01 +0000, Chris Hecker wrote:

> Yay!  Go team!

Thanks for the testing, and thanks for taking the trouble to report the
bug in the first place.

I've committed the patch to the master branch, and it will definitely be
in Emacs 29.  :-)

I'm closing the bug with this post.

> Thanks,
> Chris

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