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

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

bug#70423: 29.3; cc-mode hang at 100% cpu and consuming all available me


From: Alan Mackenzie
Subject: bug#70423: 29.3; cc-mode hang at 100% cpu and consuming all available memory
Date: Sat, 20 Apr 2024 09:22:56 +0000

Hello, M.

On Fri, Apr 19, 2024 at 20:49:20 +0000, pillowtrucker@proton.me wrote:
> Hello again, Alan!

> I've been using a git revision of hyperbole with the regex removed
> while Bob works on the new regex. I've hit a few other small glitches
> while using it, but nothing anywhere as major as the main issue at
> hand, and they're most definitely unrelated.

That's good to know, thanks.  So it seems that the C++ value of
defun-prompt-regexp is indeed the cause of the immediate problem.

What should have occurred to me immediately is that in
c-beginning-of-defun-1, I should bind defun-prompt-regexp to nil.  That
macro is intended to move to the beginning of the defun in the most
vanilla fashion possible, and for this it binds
beginning-of-defun-function, etc., to nil.  It needs to do the same to
defun-prompt-regexp.  This will likely speed it up, too.

> I also had a look in the other bug report and it seemed like there was
> also some kind of patch on the cc-mode side in emacs 30/trunk ? Or did
> I misunderstand that conversation ? I could try running an emacs git
> build if that's the case, although I'm not sure how many of my other
> packages will remain compatible, so it's not really a priority.

We're talking about bug#61436: Emacs Freezing With Java Files, I think.
There hasn't been any patch to CC Mode for this, though I think there
probably should be.  The CC Mode position is that
java-defun-prompt-regexp is unsupported and unmaintained; it is not used
at all in CC Mode.  But it is there for the convenience of other modes
(such as hyperbole) that want to copy it and use it at their own risk,
and also as an illustration of the limits of regular expressions.  The
recommendation is to use "other methods" of finding starts of defuns.

> My init.el script is really innocent, although I've later asked some
> friends and they agree that they would also probably never run
> something like that.

Yes, I see that now.  But I still don't really want to install these
packages into my Emacs, and I'm too lazy to set up an alternative
init.el.  ;-)

> I just thought it would be a fun challenge to do everything to
> reproduce the issue in one init script. The base64-encoded string is
> just a gzipped copy of the .cpp file with which I could reproduce the
> issue. You should get the same string by running "gzip --stdout
> drm_formats.cpp|base64" on the attached .cpp file. (However, I don't
> know if all gzip versions produce the same output given the same input,
> and it will make me look even more suspicious if the strings don't
> match.)

Yes, I got the C++ file without too much trouble, thanks.  I was
expecting it to be "extreme", triggering the problems in C++ Mode, but it
was just a perfectly normal C++ file.  It was on noticing hyperbole mode
that I thought about bug#61436.

> Regardless, I've been productively working on other C++ code with the
> regexp turned off and it's been a great relief not to have to struggle
> with having to restart my workspace/desktop so often.

Yes, I can understand that.  As I said, I'll fix c-beginning-of-defun-1
so that that can't possibly happen again, regardless of what happens to
these regexps.

> Thank you for both of yours work! And good luck with the new regexp!
> If you put it in some git tag/branch that I can pull easily, I could
> maybe assist with testing it ? Let me know if that's an option.

That's more up to Bob that me.

Alternatively, I could send you a copy of the new C++ regexp which you
could edit into the pertinent hyperbole source file.

> Kind regards,
> M

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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