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

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

[Chris Hecker]

[-- Attachment #1.1: Type: text/plain, Size: 470 bytes --]


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


[-- Attachment #1.2: Type: text/html, Size: 1518 bytes --]

[-- Attachment #2: Looper.h.gz --]
[-- Type: application/x-gzip, Size: 7474 bytes --]

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

[Gerd Möllmann]

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

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

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

[Eli Zaretskii]

> From: "Chris Hecker" <checker@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.

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

[Eli Zaretskii]

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

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

[Gerd Möllmann]

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.

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

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2175 bytes --]

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

[Gerd Möllmann]

Chris Hecker <checker@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 :-).

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

[Eli Zaretskii]

> Date: Sat, 5 Nov 2022 08:50:33 +0100
> Cc: checker@d6.com, 59038@debbugs.gnu.org, acm@muc.de
> From: Gerd Möllmann <gerd.moellmann@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.

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

[Eli Zaretskii]

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

bug#59038: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]


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@gnu.org>
To: "Chris Hecker" <checker@d6.com>
Cc: gerd.moellmann@gmail.com; 59038@debbugs.gnu.org; acm@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@d6.com>
>>  Date: Sat, 5 Nov 2022 01:21:34 -0700
>>  Cc: 59038@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@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.

[-- Attachment #2: Type: text/html, Size: 4547 bytes --]

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

[Phil Sainty]

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

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Chris Hecker <checker@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.

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

[Chris Hecker]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

>> (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@yahoo.com> wrote:

> Chris Hecker <checker@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.
>

[-- Attachment #2: Type: text/html, Size: 2309 bytes --]

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

[Alan Mackenzie]

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

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

[Gregory Heytings]

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

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

[Gregory Heytings]

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

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

[Phil Sainty]

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

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

[Gerd Möllmann]

Chris Hecker <checker@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.

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

[Gerd Möllmann]

Eli Zaretskii <eliz@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.

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

[Gerd Möllmann]

Phil Sainty <psainty@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.

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

[Eli Zaretskii]

> Date: Sat, 5 Nov 2022 22:03:51 +0000
> Cc: Chris Hecker <checker@d6.com>,
>   Gerd Möllmann <gerd.moellmann@gmail.com>,
>   59038@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> From: Alan Mackenzie <acm@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.

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

[Gregory Heytings]

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

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

[Eli Zaretskii]

> Date: Sun, 06 Nov 2022 09:18:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 
>     Gerd Möllmann <gerd.moellmann@gmail.com>, 
>     59038@debbugs.gnu.org, checker@d6.com, acm@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?

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

[Alan Mackenzie]

Hello, Gerd and Phil.

On Sun, Nov 06, 2022 at 06:20:17 +0100, Gerd Möllmann wrote:
> Phil Sainty <psainty@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).

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

[Alan Mackenzie]

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@heytings.org>
> > cc: Eli Zaretskii <eliz@gnu.org>, 
> >     Gerd Möllmann <gerd.moellmann@gmail.com>, 
> >     59038@debbugs.gnu.org, checker@d6.com, acm@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).

bug#59038: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely

[Chris Hecker]

Yay!  Go team!

Thanks,
Chris

------ Original Message ------
From: "Alan Mackenzie" <acm@muc.de>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: "Gregory Heytings" <gregory@heytings.org>; psainty@orcon.net.nz; 
gerd.moellmann@gmail.com; 59038@debbugs.gnu.org; checker@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@heytings.org>
>>  > cc: Eli Zaretskii <eliz@gnu.org>,
>>  >     Gerd Möllmann <gerd.moellmann@gmail.com>,
>>  >     59038@debbugs.gnu.org, checker@d6.com, acm@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).

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

[Gerd Möllmann]

Alan Mackenzie <acm@muc.de> writes:

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

Works for me.  Thanks, Alan!

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

[Alan Mackenzie]

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