Under certain circumstances, switching to another project git branch causes Atom to occupy all available memory and freeze the system. #1002
Description
Description
On Linux, if a project's folder structure is changed or files renamed or (re-) moved in one git branch, switching to a another ("older") git branch via Linux Bash (not the integrated git features) causes Atom (1.18.0 x64) to suddenly occupy all available memory and ultimately freeze the system.
Steps to Reproduce
- Start some new git project with "git init".
- Create a folder, say "src_old", throw files into them, edit them, commit (to "master" branch).
- Create a new branch "feature" ("git checkout -b feature")
- Close all files in Atom.
- Use git to rename folder to say "src_new" ("git mv src_old src_new")
- Re-open all files from new location in Atom.
- Edit files and commit (a few times).
From here, to paths can lead to the problem. In both cases, all files in "src_new" are opened in Atom.
Path A:
A.8. Close Atom.
A.9. Checkout "master" (which still contains the old layout with "src_old") with "git checkout master".
A.10. Re-open Atom.
Path B:
B.9. Checkout "master" (which still contains the old layout with "src_old") with "git checkout master".
Expected behavior:
In both modes, I'd expect that the still opened files from "src_new" would have a blue dot in their tab, indicating that they have not been saved (because "src_new" does not exist in branch "master"). I'd close them, telling Atom not to save them. In mode A, Atom should present a bunch of empty tabs to me (at least this is what I remember from previous versions).
Actual behavior:
Atom "flickers", in mode A opens up with a bunch of empty tabs, and fills up all available memory pretty quickly (in ~2 seconds) until the system becomes completely unresponsive.
When I reset my computer, (re-)boot the system and start Atom again it might just as well happen again - unless I delete my .atom configuration folder.
Reproduces how often:
It does not reproduce reliably, at least I have not found a way to make this happen all the time. Sometimes, when the memory is filled, the system recovers after a few minutes and things go back to normal (Atom uses about as much memory as before). One strange aspect is that I do not see swapping happening in monitoring tools (though the harddrive's noise is clearly indicating that swapping is happening). If the system recovers, nothing (not even other processes) ended up in swap - although this happens on my system when other processes cause me to run out of memory. On a system with 8 GByte of memory and an old-fashioned hard-drive the described problem happens more often to me (and the system rarely recovers). On a system with 32 GByte of memory and an SSD, it virtually never happens though I can observe a really quick spike in memory usage. My impression is that more commits in the new branch and longer system uptimes "improve" the likelihood of the described behavior.
In a nutshell: About 50%.
Versions
~> atom --version
Atom : 1.18.0
Electron: 1.3.15
Chrome : 52.0.2743.82
Node : 6.5.0
~> apm --version
apm 1.18.1
npm 3.10.10
node 6.9.5 x64
python 2.7.13
git 2.12.3
~> uname -a
Linux e7 4.4.70-18.9-default #1 SMP Wed May 31 09:09:25 UTC 2017 (c1231a7) x86_64 x86_64 x86_64 GNU/Linux
I am running openSUSE Leap 42.2.
Additional Information
I deleted my .atom configuration folder - it also happens with a vanilla configuration with only default plugins installed.