Community
Participate
Working Groups
Created attachment 280687 [details] Eclipse not responding, plus wrong CPU usage reporting Out of memory error and CPU usage at 683% while right-clicking on a git repository for getting information. Notes: - This kind of freeze happens frequently. As a result, Eclipse's usability on Mac feels very poor. - The reporting of CPU usage (and CPU time) to the MacOs system is wrong. Details: - eclipse-SDK-I20191113-2315 + Tools for Developers (as per Platform Dev. guide) - using theme Dark [Windows] (because no dark mac is available) - eclipse Platform UI projects loaded in the workspace Eclipse SDK Version: 2019-12 (4.14) Build id: I20191113-2315 OS: Mac OS X, v.10.15.1, x86_64 / cocoa Java version: 10.0.1
Created attachment 280688 [details] Error log for the session
Can you please create a thread dump via jstack and heap dump + heap histogram via jmap?
Created attachment 280689 [details] State of the UI and List of errors - just before eclipse shutdown
(In reply to Andrey Loskutov from comment #2) > Can you please create a thread dump via jstack and heap dump + heap > histogram via jmap? Eclipse was unresponsive and then I had to restart it. Hence, I cannot create a thread dump for that session. I will create a thread dump the next time I get the same error.
Patrik, can you please point to the git repository you were working with, if it is open source? Which egit version are you using?
I was working with the Eclipse I20191113-2315 plus the development tools installed via the psf provided in the Platform/How_to_Contribute [ref.1]. No other plugins were installed. When I got the error, I had four repositories open: - the three repositories listed in p2f provided in Platform/How_to_Contribute [ref.2], plus a local repository [ref.1] https://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUiTools.p2f [ref.2] http://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUiProjectsGerrit.psf
How did you end up with a git repository in your user home directory? Is that intentional? What happens if you do $ cd ~ $ git status ?
If unintentional: before deleting that ~/.git folder, please check the contents of directory ~/.git/hooks. If it contains *.sample files, it was created by command-line git. If it's empty, it was created by JGit. In that case I'd like to know what you did in Eclipse to make EGit/JGit create a git repo there...
(In reply to Thomas Wolf from comment #7) > How did you end up with a git repository in your user home directory? Is > that intentional? No, unintentional. > What happens if you do > > $ cd ~ > $ git status > > ? After a few seconds, I get the status. All the actual repositories result modified, while other files/folders are untracked. (In reply to Thomas Wolf from comment #8) > If unintentional: <...> check contents of directory ~/.git/hooks. > If it contains *.sample files, it was created by command-line git. > If it's empty, it was created by JGit. <...> Indeed, there are .sample files. So, it was not created by JGit.
(In reply to Andrey Loskutov from comment #2) > Can you please create a thread dump via jstack and heap dump + heap > histogram via jmap? I reproduced the issue, it's related to the staging view. I generated the logs with the following script pid=39857 &&\ tst=$(date '+%Y%m%d_%H%M%S') &&\ jstack -l "${pid}" >> "dumps/threaddumps-${pid}-${tst}.log" &&\ jmap -J-d64 -histo:live "${pid}" >> "dumps/jmapheap-histo-${pid}-${tst}.log" With the next two comments, I'll attach the thread dump and the heap histogram.
Created attachment 280708 [details] Thread dump
Created attachment 280709 [details] Heap histogram. Note: I also generated a heap dump, but it's 1.45 GB. I guess I can't attach it here.
Created attachment 280710 [details] Weird error message: An internal error occurred while showing an internal error. Bonus: weird error of the day!
The "weird error" is not weird at all. In fact, I'm surprised you get a reasonable error dialog when the JVM has run out of memory. Remove that ~/.git repository from Eclipse. It's bound to have millions of unstaged files, and the staging view is trying to add a million items to a TreeViewer. (To be precise: according to your heap histogram, it's 1072037 unstaged files in 313718 directories.) If you can't remove it the IDE because of these OOMs, do it outside Eclipse: open the file .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.egit.core.prefs in your workspace directory and remove "/Users/psuzzi/.git" from the two keys "GitRepositoriesView.GitDirectories" and "GitRepositoriesView.GitDirectories.relative". Then delete that spurious ~/.git directory including its contents. Then start Eclipse again.
(In reply to Thomas Wolf from comment #14) > The "weird error" is not weird at all. In fact, I'm surprised you get a > reasonable error dialog when the JVM has run out of memory. > > Remove that ~/.git repository from Eclipse. It's bound to have millions of > unstaged files, and the staging view is trying to add a million items to a > TreeViewer. (To be precise: according to your heap histogram, it's 1072037 > unstaged files in 313718 directories.) Maybe we should teach the StagingView not to try loading such a mass of unstaged files. Who wants to scroll 1 mio files in a view ?
(In reply to Matthias Sohn from comment #15) > Maybe we should teach the StagingView not to try loading such a mass of > unstaged files. Who wants to scroll 1 mio files in a view ? We have already a preference for "compact" mode, limit is 10000. May be add a limit for other modes as well?
(In reply to Matthias Sohn from comment #15) > Maybe we should teach the StagingView not to try loading such a mass of > unstaged files. Who wants to scroll 1 mio files in a view ? Perhaps. Though the interesting thing is: Patrik even has two commits in that ~/.git repo, and the file diff viewer in the history view (see his screenshot [1]) apparently can display fine. The scrollbar thumb in that view is small, so I suppose there's quite a lot of files in that commit, too. The CommitFileDiffViewer uses a virtual table, though. Patrik, how many files are in commit 919ad39 in ~/.git? You can find out by doing $ cd ~ $ git diff-tree --no-commit-id --name-only -r 919ad39 | wc -l [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=280687
(In reply to Thomas Wolf from comment #17) > Patrik, how many files are in commit 919ad39 in ~/.git? You can find out by > doing > > $ cd ~ > $ git diff-tree --no-commit-id --name-only -r 919ad39 | wc -l > > [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=280687 :~ (master) $ git diff-tree --no-commit-id --name-only -r 919ad39 | wc -l 5148
(In reply to Patrik Suzzi from comment #18) > $ git diff-tree --no-commit-id --name-only -r 919ad39 | wc -l > 5148 While large it's clearly a number that SWT trees/tables can handle easily. So yes, we should perhaps add some absolute upper limit for these viewers in the staging view. But then? Staging a million files likely is going to have problems, too. If the user manages to commit the changes, we have a commit with a million items (and a git tree with a million items). If the user tries to show that commit in the history view, we'll add a million items to the CommitFileDiffViewer. If he opens the commit viewer on that commit, we'll try to produce a unified diff of a million items, and the outline will try to show a million items. There'll be a million items in the index, and index diff will take a while. This is just not going to work at all. My suggestion is not to do anything in software for this. Better run into an OOM, get a bug report, and then advise the user not to do such things.
(In reply to Thomas Wolf from comment #19) > My suggestion is not to do anything in software for this. Better run into an > OOM, get a bug report, and then advise the user not to do such things. IMHO, the real problem is the UI is blocked during the operation. Hence, I think we should identify the UI-blocking component, and instead of blocking, perform an asyncExec.
(In reply to Patrik Suzzi from comment #20) > IMHO, the real problem is the UI is blocked during the operation. Hence, I > think we should identify the UI-blocking component, and instead of blocking, > perform an asyncExec. Filling in a tree necessarily has to happen on the UI thread.
(In reply to Thomas Wolf from comment #21) > Filling in a tree necessarily has to happen on the UI thread. I thought we should be able to precompute a model and then set it into the tree, perhaps with a TreeContentProvider. Anyway, I think there is another use case to consider: 1. When I set-up the workspace, I just import a Team Project Set [ref.1] with no reference to the ~/.git repository. 2. And then, the repository in ~/.git is automatically added to the repository view (that is unjustified as there is no reference to it in the .psf). 3. Finally, when I right-click that ~/.git repo to remove it from the view, 50% of times, Eclipse becomes unresponsive. [ref.1] http://git.eclipse.org/c/platform/eclipse.platform.ui.git/plain/releng/org.eclipse.ui.releng/platformUiProjectsGerrit.psf
(In reply to Patrik Suzzi from comment #22) > 1. When I set-up the workspace, I just import a Team Project Set [ref.1] > with no reference to the ~/.git repository. > > 2. And then, the repository in ~/.git is automatically added to the > repository view (that is unjustified as there is no reference to it in the > .psf). Now that's something we can try to fix.
New Gerrit change created: https://git.eclipse.org/r/153436
Note: I wanted to check your change on gerrit, and I first checked how it works now on master. I observed the issue is already resolved with the master version of EGit. To test, I just cloned EGit and JGit projects locally and launched a new Eclipse instance with the contained plugins. Then, in the new Eclipse (inner) instance, I verified that when I import a .psf file, the main ~/.git repository is not automatically imported.
Thanks for the double check, but for me it does occur. If I create a ~/.git by running git init in my home directory, start a child Eclipse in a new workspace, change the default directory for git directories to some new directory (because I already have EGit clones with a different URL) and then import the egit.psf, then open the git repositories view, I end up with ~/.git in the repositories view. The change makes sure that this doesn't happen anymore.
(In reply to Thomas Wolf from comment #26) > change the default directory for git directories to some new directory To be precise: to ~/git2. The problem occurs only if the location for the cloned repositories is underneath ~. Which is normally the case; the default is ~/git.
Gerrit change https://git.eclipse.org/r/153436 was merged to [stable-5.6]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=6dad437624f1ab9796ddf6395b248d58607a3958
