Community
Participate
Working Groups
The option Team -> Synchronize Workspace for a git cloned project freezes the Eclipse entirely in Eclipse Photon.
Can you provide any more details? Does the same occur on Oxygen? If you update EGit in Oxygen to Egit 5.0.1 or 5.1 (nightly), does it still occur in Oxygen? How exactly does it freeze? Is the repository public, and if so, how could I reproduce the issue? Can you take some stack dumps while it is frozen (jstack is fine)? Do other operations (including fetch and push, decorator updates, git staging view) work normally?
Unfortunately, the repository is private. The issue seems to exist only in this specific workspace. I have switched with the same Eclipse Photon instance on another workspace with 2 git projects on the same internal git server without any issue. I have performed git sync and the process is stuck again: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29215 panos 20 0 6259948 1.088g 50184 S 106.7 7.0 2:27.66 java occupying 100% of the CPU. The jstack is provided in the attached file "eclipse-jstack.txt". In the screenshot "frozen-eclipse-photon-with-git-sync.png" you may see the Eclipse window completely frozen, where nothing is displayed in the main window, but only the last desktop area.
Created attachment 275108 [details] eclipse-jstack.txt
Created attachment 275109 [details] frozen-eclipse-photon-with-git-sync.png
There's _no_ org.eclipse.egit in these stack traces. Only org.eclipse.team. Did something change over there?
Nothing has changed. I believe the problem is here: ----------- "Worker-3: Synchronizing Git" #37 prio=5 os_prio=0 tid=0x00007f9cf41f8000 nid=0x7267 waiting on condition [0x00007f9c91656000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a0194828> (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:409) at org.eclipse.ui.internal.PendingSyncExec.acquire(PendingSyncExec.java:35) ----------- It waits for a semaphore notification that never arrives!?
(In reply to Panos Kavalagios from comment #6) > Nothing has changed. I believe the problem is here: > > ----------- > "Worker-3: Synchronizing Git" #37 prio=5 os_prio=0 tid=0x00007f9cf41f8000 > nid=0x7267 waiting on condition [0x00007f9c91656000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000a0194828> (a > java.util.concurrent.Semaphore$NonfairSync) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer. > doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer. > tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:409) > at > org.eclipse.ui.internal.PendingSyncExec.acquire(PendingSyncExec.java:35) > ----------- > > It waits for a semaphore notification that never arrives!? It waits for the main thread to finish and process the syncExec. The main thread is running (not blocked) and busy with some viewer refresh. My point was: EGit is not present in the stack traces at all. So whatever is going on doesn't appear to be EGit-related. There have been changes in org.eclipse.team[1]. Most seem to have been clean-ups; from the commit messages I don't see anything relating to these stack traces. But maybe some clean-up went wrong... Perhaps you could try to take several jstack traces while it's blocked? Perhaps that'll tell us more. [1] https://git.eclipse.org/c/platform/eclipse.platform.team.git/log/
Created attachment 275117 [details] eclipse-jstack.zip Yes, maybe it is not related to EGit. I was also able to Pull changes without issue. I have uploaded eclipse-jstack.zip for running jstack to the eclipse java process every 10 seconds.
Correction, it is not stuck, but it is taking too long. I have left the workspace for more than an hour and it now displayed the changes in the team synchronization window. I have pressed the + sign to expand the differences and it will take again too long I suppose. So, the original problem can be stated as Synchronize Workspace of Git Team Provider takes too long by making the entire Eclipse unresponsive.
Even in the multiple stack traces in the zip file there's not a single mention of org.eclipse.egit. For most of the traces, org.eclipse.team appears to be stuck (temporarily) at org.eclipse.team.internal.core.subscribers.AbstractSynchronizationScope.getRoots(AbstractSynchronizationScope.java:40) and all traces are within at org.eclipse.team.ui.mapping.SynchronizationContentProvider.internalGetChildren(SynchronizationContentProvider.java:123) at org.eclipse.team.ui.mapping.SynchronizationContentProvider.getElements(SynchronizationContentProvider.java:52) at org.eclipse.team.internal.ui.mapping.ResourceModelContentProvider.getElements(ResourceModelContentProvider.java:315) at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.getElements(SafeDelegateTreeContentProvider.java:101) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider$1.run(NavigatorContentServiceContentProvider.java:154) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.internalGetChildren(NavigatorContentServiceContentProvider.java:143) at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.getElements(NavigatorContentServiceContentProvider.java:116) ... at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1530) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:535) at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:349) at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:492) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1466) at org.eclipse.ui.internal.navigator.extensions.StructuredViewerManager$2$1.run(StructuredViewerManager.java:219) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.navigator.extensions.StructuredViewerManager$2.run(StructuredViewerManager.java:215) at org.eclipse.ui.internal.PendingSyncExec.run(PendingSyncExec.java:58) It's a viewer refresh. No idea why that takes so long. In comment 2, you wrote: (In reply to Panos Kavalagios from comment #2) > The issue seems to exist only in > this specific workspace. I have switched with the same Eclipse Photon > instance on another workspace with 2 git projects on the same internal git > server without any issue. Is it the workspace or the repository? * Does it occur with the same clone of the same repo (and the same changes) in some other workspace? * Does it occur with a new clone of the same repo and the same changes in * the same (problematic) workspace? * in some other workspace?
And of course: is there anything in the error log?
Created attachment 275125 [details] eclipse-workspace-log.txt Please find my answers below: - Even in the multiple stack traces in the zip file there's not a single mention of org.eclipse.egit. - Let me know if I have to re-assign the ticket to another more appropriate product/component. - Is it the workspace or the repository? - It is an Eclipse workspace - Does it occur with the same clone of the same repo (and the same changes) in some other workspace? - Yes, it occurs in a new workspace with the same git repository. - Does it occur with a new clone of the same repo and the same changes in * the same (problematic) workspace? * in some other workspace? - It occurs every time in the same or other workspaces for this specific Git repository. You may also find attached the log file from a newly created workspace. I believe I have isolated the problem. It occurs when I import the existing Maven Projects. This specific git repository has 4 levels (!) of nested maven projects. If I do not import the maven projects the Git Synchronize is really fast, but with the Maven Projets imported, it takes too long. The Synchronize View displays a change multiple times for all projects found in the workspace (parent and its children).
(In reply to Panos Kavalagios from comment #12) > - Is it the workspace or the repository? > - It is an Eclipse workspace Your other answers clearly indicate that not the particular Eclipse workspace is the culprit, but the git repository, and the deeply nested maven projects. > If I do not import the maven projects the Git Synchronize is > really fast, but with the Maven Projets imported, it takes too long. The > Synchronize View displays a change multiple times for all projects found in > the workspace (parent and its children). So it looks like a problem with the synchronize view and (deeply) nested projects. Whether that comes from EGit or not is unclear at this point.
I apologise for the confusion. We have already many git repositories with nested by four levels and they don't seem to have an issue. I have imported one by one the projects and it seems that it is related to a specific project that have many files (20k). I understand that it is related to Bug 517160. The present ticket can be closed as a duplicate of the mentioned bug.
