Spacemacs gets stuck for a few seconds and hogs CPU(100% usage) from time to time #1369
Comments
|
Deleted both |
|
FYI, I recently ran into an issue of noticeable stuck when doing copy and paste. I eventually was able to find out it's related to |
|
Now it happened again... without any private layer. And Emacs just stuck at 100% CPU forever. Also the incessant memory increase is back.
I'm not sure whether it could be related to #1263 ... At such a state of affairs I'm afraid I won't be able to use Spacemacs until I figure out what's happening at all... |
|
If no layer is included, probably it's the problem of your Emacs build. Maybe instead of emacs-mac-port, you should give Emacs for Mac OS X latest build (24.5) a try, since the new version fixed crashing bug in 24.4. If that doesn't work and you still have patient, probably try the development version Emacs 25. |
|
@tuhdo Will give it a try. The only issue with Emacs for Mac OS X compared with emacs-mac-port is the powerline color issue, right? |
|
I'm having this problem as well, on OSX 10.9.5. I've tried with Emacs 24.5.1 Universal, the 26th April and the 20th April nightlies from EmacsForOSX. In the case of the Nightlies, Emacs doesn't open itself. In the case of 24.5.1, Emacs opens, but when I try to do C-x C-f, it hangs and hogs the CPU at 99-100%. :-( |
|
Yeah, Emacs for OSX has the same problem too... And sometimes just as described in #1300, it not only hogs CPU, but seems to increasingly require more and more memory until it has eaten up all disk space(presumably making virtual memory?) as well. In my case it has requested nearly 30GB of memory accordingly to Activity Monitor. That's quite monstrous. |
|
Since you are using old OSX 10.9.5, consider upgrading to latest OS X Yosemite or downgrade Emacs to emacs-mac-port 24.4 or even 24.3. I don't think it has any problem with latest OS X since many people are using Emacs 24.5 on it. |
|
Unfortunately for me I'm using the newest version of Yosemite... :( |
|
So, try reproducing it with just stock Emacs: |
|
Now I'm trying to build Installation command: Edit: sorry, no |
|
Ah no. The problem resurfaced. But it's actually killable via |
|
I got stuck again today on Emacs startup process as it started to infinitely hog CPU and memory again. I inspected my |
|
That's not normal at all. Probably you should temporary disable |
|
Running Could it be anything to do with |
|
You |
|
I ran into a similar problem last night, which persisted across resetting my |
|
In my case I can currently confirm that an abnormally large |
|
The We can see that the problematic variables @x-ji encountered are added explicitly by spacemacs. |
|
We should only disable saving those variables (or just |
|
The issue with these variables are only on OS X ? |
|
I have no such abnormal large savehist in both my Linux and Windows machine. Not sure about which version of Emacs in OS X. |
|
Well for me it happened in all kinds of emacs builds, including emacs-mac, Not sure I'm copying anything abnormal, especially considering it happens On Thu, May 21, 2015, 10:45 Tu Do notifications@github.com wrote:
|
|
My guess is images/documents in clipboard interacting with |
|
@tuhdo removed the kill-ring from savehist which should fix the issue. |
1. Use an idle timer instead of a strict periodic autosave interval. Saving large histories can cause noticable delays, and the default `history-length` set by Spacemacs is relatively large (1000). 2. Save `kill-ring` without text properties, as they are known to cause significant performance problems and huge history files in some cases, and persisting them in the kill-ring usually brings little benefit. This should fix syl20bnr#1300, syl20bnr#1369 and syl20bnr#9409 again. 3. Add `kmacro-ring` and `log-edit-comment-ring` as additional variables. They are useful and usually not very large. BTW, `search-ring`, `regexp-search-ring` and `extended-command-history` are redundant here as long as long as `savehist-save-minibuffer-history` is non-nil (the default). I decided to leave them there for now to avoid any breaking changes for users that customized that option, though I guess it could be okay to change this.
1. Use an idle timer instead of a strict periodic autosave interval. Saving large histories can cause noticable delays, and the default `history-length` set by Spacemacs is relatively large (1000). 2. Save `kill-ring` without text properties, as they are known to cause significant performance problems and huge history files in some cases, and persisting them in the kill-ring usually brings little benefit. This should fix #1300, #1369 and #9409 again. 3. Add `kmacro-ring` and `log-edit-comment-ring` as additional variables. They are useful and usually not very large. BTW, `search-ring`, `regexp-search-ring` and `extended-command-history` are redundant here as long as long as `savehist-save-minibuffer-history` is non-nil (the default). I decided to leave them there for now to avoid any breaking changes for users that customized that option, though I guess it could be okay to change this.
Now #1300 is solved, Emacs no longer eats up memory and totally freezes.(Update: #1300 now happened again as well...) However, I still encounter random situations where Emacs just ramps up its CPU usage all the way to 100% from time to time, and gets stuck for at least 5 seconds. It happens almost every 30 seconds now.The first screenshot is when CPU usage peaks. Subsequently it drops rapidly to only about 1% and Emacs responds normally again.
When this happens I'm not doing anything except for navigating a file using Vim bindings. It's weird because I've erased all the variables set via
Custombut it doesn't help.Also, pressing
SPCand mouse-clicking on Emacs could both also induce the issue.I think other users mentioned similar situations in both #1300 (comment) and #868 (comment)
The text was updated successfully, but these errors were encountered: