GNU bug report logs -
#61436
Emacs Freezing With Java Files
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 14 Oct 2023 19:41:41 +0000
with message-id <ZSru9aiO614QDrR5 <at> ACM>
and subject line Re: bug#61436: Emacs Freezing With Java Files
has caused the debbugs.gnu.org bug report #61436,
regarding Emacs Freezing With Java Files
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
61436: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61436
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
I have a few Java files that are about 500 lines of code and I can't move around in them much before Emacs freezes. I first thought it was java-lsp but it still happened after disabling and uninstalling it. I also uninstalled lsp-mode as well, but that didn't change anything.
I started doing CPU profiles of it and found that which-function-mode was taking up 67% of my CPU usage. While this is happening all I was doing was holding the down arrow until it froze about 350 lines in. Didn't press any other buttons.
So I disabled which-function-mode and moved around the buffer just fine! Though when trying to edit the file (just hit enter), it froze again. This time it seems like electric-indent-mode was taking up close to 50% of my CPU usage.
I disabled that and tried again and then it froze again with c-indent-line-or-region eating up 63% of my CPU when I use TAB.
While using debug-on-quit I get the below output. Any idea what's happening here and how it can be addressed? I do know though that if I launch emacs with the -Q argument, then there aren't any problems at all. I tried large files of other types and it only seems to happen with Java files. I attached screenshots of the CPU profiler outputs for each of the three scenarios. Attached is also the Java file as well as my init file.
I am using emacs version 28.2 on EndeavorOS, but reproduced the results using both emacs 29 and the master branch.
Debugger entered--Lisp error: (quit)
beginning-of-defun()
c-get-fallback-scan-pos(17794)
c-parse-state-get-strategy(17794 1)
c-parse-state-1()
c-parse-state()
c-guess-basic-syntax()
c-indent-line()
#f(compiled-function () (interactive nil) #<bytecode 0x180248dcca1cc57e>)()
c-indent-command(nil)
c-indent-line-or-region(nil nil)
funcall-interactively(c-indent-line-or-region nil nil)
call-interactively(c-indent-line-or-region nil nil) command-execute(c-indent-line-or-region)
[Message part 4 (text/html, inline)]
[emacs-freezing-cpu-profile-indent-mode-off.png (image/png, attachment)]
[emacs-freezing-cpu-profile.png (image/png, attachment)]
[emacs-freezing-cpu-profile-no-function-mode.png (image/png, attachment)]
[P1.java (text/x-java, attachment)]
[init.org (text/org, attachment)]
[Message part 10 (message/rfc822, inline)]
Hello, Jens and Mats.
On Fri, Oct 13, 2023 at 22:42:04 +0200, Jens Schmidt wrote:
> Hi Alan,
> Alan Mackenzie <acm <at> muc.de> writes:
> > To solve the bug, I'm amending the macro c-beginning-of-defun-1 so that
> > it only stops at a debug-prompt-regexp position when it also found a {.
> > Otherwise it will keep looping until it finds a better position or BOB.
> Thanks.
> > Then please confirm that the bug is indeed fixed.
> For the fun of it I tried Hank's initial testcase as well, which is a
> bit less straight-forward to set up. The freezes are indeed gone with
> your patch.
Thanks for the testing. Seeing as how both of you confirm the original
bug is fixed with the patch, I'm closing it with this post.
> But I noticed that which-function-mode, when rapidly moving through
> the file, cannot always determine the current function name, then
> displaying "[n/a]" in the mode line.
> And indeed, when executing the simplified test case
> ./src/emacs -Q -l ~/tmp/init.el +181 ~/tmp/P1.java
> and then immediately hitting C-M-a, point jumps to the beginning of the
> preceeding catch clause (point=5779 of 18142) instead of BOD.
I can't reproduce this, even when setting defun-prompt-regexp to the
original large regexp from hui-select.el.
> This behavior is again tied to the `defun-prompt-regexp' used by
> Hyperbole - without that regexp C-M-a jumps to the real BOD.
Mats, I'm willing to work on that regular expression, and also the one
for C++. As I mentioned earlier, I've got some tools which work on
regexps, in particular pp-regexp, which prints a regexp more readably on
several lines, and fix-re, which rewrites a regexp when it is
ill-conditioned in certain ways.
I foresee reverse engineering the regexps into more readable forms built
up by concatenating basic blocks. For example for the java regexp I
would define
(defconst id "[a-zA-Z][][_$.a-zA-Z0-9]*")
, and use this id in a largish concat form.
I'm also willing to share pp-regexp and fix-re with you(r team), if that
might help, on the understanding that neither is of release quality.
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 1 year and 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.