Community
Participate
Working Groups
Created attachment 220366 [details] Eclipse Config Unfortunately I cannot start Eclipse with certain workspaces anymore. I attached two threaddumps which show, that the m2e thread is blocked during calculating a checksum. Also I attached my Eclipse config.
Created attachment 220367 [details] Threaddump2
Created attachment 220368 [details] Threaddump1
Created attachment 220369 [details] Threaddump3 Threaddump1 & 2 are taken during Eclipse start with Java 6, the same error occurs during startup with Java 7 (Threaddump 3)
Seems that this is a race condition between the latest SVNKit Connector for subversive and m2e, since m2e is waiting for a lock which is currently hold by SVNKit Connector.
From the thread dumps * m2e background job is waiting for jvm internal classloading lock held by subversive. Background jobs do not block UI, so m2e is not the cause of "cannot start Eclipse" problem according to the attached thread dumps * UI thread (which subversive renamed to SVN-XXXXX) is running some svn-related code. I do not know enough about svn to tell if the thread is locked or the subversive/svnkit operation just takes very long time to complete. UI is trying to display history view, so closing the view may workaround the problem Moving to subversive for further investigation.
Hi Igor, thanks for your analysis, you are right, seems to be a problem with Subversive. I can even reproduce with the old SVNKit connector 1.7.4 now (compare with Threaddump4).
Created attachment 220380 [details] Threaddump4 Thread Dump using the SVNKit 1.7.4 Implementation (Optional) 3.0.0.I20120601-1700
Ok, this is some AWT related issue on the Mac. Starting Eclipse with -Djava.awt.headless=true solves this deadlock. I think the key problem is that the main thread is loading JNA (which itself loads AWT), but I'm not sure why this should be a problem.
Compare with http://issues.tmatesoft.com/issue/SVNKIT-309?projectKey=SVNKIT. There is another workaround suggested, to load JNA before AWT but I guess this cannot be applied for Eclipse.
I ran into this issue as well. Not sure if it will help, but I'll add what I've found: * Fresh Eclipse Juno (Java Package) with only Subversive 1.0.0 installed (from Eclipse marketplace). When using svnkit 1.3.8, Eclipse freezes during startup (says "Loading Workspace"). This is with an empty workspace (no projects). However, if I remove the workspace it will start. But if I then restart, Eclipse will freeze again on startup. If I use svnkit 1.7.5.v1 it seems as Eclipse doesn't freeze. Haven't tested this extensively though so I can't say for sure. The workaround with -Djava.awt.headless=true fixes the freezing on startup.
*** Bug 388888 has been marked as a duplicate of this bug. ***
*** Bug 388387 has been marked as a duplicate of this bug. ***
*** Bug 391827 has been marked as a duplicate of this bug. ***
@Anders Hammar Thank you. This worked for me. It has been driving me nuts for weeks. Even thought about using external SVN software. Thanks that I found your post. For those as confused as me, you will need to put this line "-Djava.awt.headless=true" in the eclipse.ini file (i put it on a new line at the end of the file) On my machine this file is found here $PATH_TO_ECLIPSE_INSTALL_DIR/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini
*** Bug 392623 has been marked as a duplicate of this bug. ***
*** Bug 397894 has been marked as a duplicate of this bug. ***
Note that unfortunately the above suggested workaround itself can generate some trouble in combination with other features, for instance MDT/papyrus. This exception occurs when selecting an element in a diagram. java.awt.HeadlessException at sun.awt.HeadlessToolkit.getSystemClipboard(HeadlessToolkit.java:286) at org.eclipse.papyrus.uml.diagram.common.providers.PapyrusDiagramGlobalActionHandler.canPaste(PapyrusDiagramGlobalActionHandler.java:65) at org.eclipse.gmf.runtime.diagram.ui.render.internal.providers.ImageSupportGlobalActionHandler.canHandle(ImageSupportGlobalActionHandler.java:72) at org.eclipse.gmf.runtime.common.ui.action.global.GlobalAction.refresh(GlobalAction.java:161) at org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandler.selectionChanged(AbstractActionHandler.java:387) at org.eclipse.papyrus.infra.core.sasheditor.internal.eclipsecopy.MultiPageSelectionProvider$1.run(MultiPageSelectionProvider.java:113) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.papyrus.infra.core.sasheditor.internal.eclipsecopy.MultiPageSelectionProvider.fireEventChange(MultiPageSelectionProvider.java:110) at org.eclipse.papyrus.infra.core.sasheditor.internal.eclipsecopy.MultiPageSelectionProvider.fireSelectionChanged(MultiPageSelectionProvider.java:92) at org.eclipse.papyrus.infra.core.sasheditor.internal.eclipsecopy.MultiPageEditorSite4x.handleSelectionChanged(MultiPageEditorSite4x.java:588) at org.eclipse.papyrus.infra.core.sasheditor.internal.eclipsecopy.MultiPageEditorSite4x$4.selectionChanged(MultiPageEditorSite4x.java:503) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramGraphicalViewer.flushSelectionEvents(DiagramGraphicalViewer.java:256) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramGraphicalViewer$1.run(DiagramGraphicalViewer.java:234) [...]
This issue gives a hint on how to fix this: https://github.com/twall/jna/issues/155
I could pretty easily fix this in JNA given an alternative method to checking whether AWT is available (currently the code just does "Class.forName("java.awt.Component")").
JNA cares about two scenarios: is AWT available at all on a given platform (e.g. android or other mobile environment) and whether the system is headless. Currently the two things are conflated in the java.awt.Component check.
*** Bug 404846 has been marked as a duplicate of this bug. ***
I run today into this as well. The work-around from comment 14 didn't help. Running latest on OS X 10.7.5 I suggest raising this bugs priority
I run today into this as well. The work-around from comment 14 didn't help. Running latest on OS X 10.7.5 I suggest raising this bugs priority.
JNA no longer does `Class.forName("java.awt.Component")`, so an upgrade of JNA within svnkit should fix the problem. This change was made around 10/2012 for version 3.5.2 of JNA.
Then it must be something else. Shall I file a new bug?
BTW, unfortunately I can't reproduced it anymore. A "/Application/Eclipse/eclipse -D foobar" did the trick to get me out of the mess. foobar was an empty dir. After that I managed to reopen my production workspace again.
This is still not fixed in Subversive in the latest SVNKit (1.7.11). Please compare with the bug report directly for SVNKit at http://issues.tmatesoft.com/issue/SVNKIT-309. In the new beta (1.8.x) JNA in version 3.5.2 is included (compare with dependencies in http://svn.svnkit.com/repos/svnkit/tags/1.8.0-beta/build.gradle), therefore the bug should not occur with that beta. However, there is currently no connector for SVNKit 1.8.
(In reply to Konrad Windszus from comment #27) > This is still not fixed in Subversive in the latest SVNKit (1.7.11). Please > compare with the bug report directly for SVNKit at > http://issues.tmatesoft.com/issue/SVNKIT-309. In the new beta (1.8.x) JNA in > version 3.5.2 is included (compare with dependencies in > http://svn.svnkit.com/repos/svnkit/tags/1.8.0-beta/build.gradle), therefore > the bug should not occur with that beta. However, there is currently no > connector for SVNKit 1.8. There is a SVN Kit 1.8.0 connector available on the latest stable build update site: http://community.polarion.com/projects/subversive/download/eclipse/3.0/update-site/
Hi, Running latest 10.7.5 still hung on loading org.eclipse.mylyn.tasks.ui even after updating eclipse.ini with "-Djava.awt.headless=true" as mentioned in Comment 14. To Resolve: Since Subclipse is loaded/updated from Eclipse Marketplace WHILE Eclipse is up and running, I created a new empty directory and pointed Eclipse workspace at it, updated to Subclipse 1.8 taking default options, then upon restart pointed back at my old workspace and Eclipse finally was able to start.
Still there in Kepler. And the worse thing: I don't use Mylyn. Well there is a simple work around: >cd /Applications/Developer/eclipse/kepler >del **/*mylyn* >deltree features/org.tigris.subversion.subclipse.mylyn_3.0.0 Never know why the Mylyn plugins where there in the first place.
Is this the root cause? https://bugs.openjdk.java.net/browse/JDK-8013560
Comment 31 worked for me
I have been running into this problem once or twice every month for last 2 years. In my case this happens mostly when machine is restarted without exiting Eclipse. I will try with "-Djava.awt.headless=true" and see if that prevents it. Following steps fixes it once it happens Perform the following steps in the workspace Directory: 1. cd .metadata/.plugins 2. mv org.eclipse.core.resources org.eclipse.core.resources.bak 3. Start eclipse. It will show an error message and/or an empty workspace as no project is found. 4. Close all open editors tabs. 5. Exit eclipse. 6. rm -rf org.eclipse.core.resources -- (Delete the newly created directory.) 7. mv org.eclipse.core.resources.bak/ org.eclipse.core.resources (Restore the original directory.) 8. Start eclipse and start working. ;-) Before I found these steps, I was deleting old workspace and creating new :(
-Djava.awt.headless=true fixed it this time. Without doing anything to .metadata/.plugins/org.eclipse.core.resources directory.
I use eclipse -clearPersistedState when I met this problem. I don't know what exact reason is, ignoring persisted workbench state can avoid dead lock.
hi I faced similar problem (eclipse hangs on some events) with my eclipse 3.7 indigo x64 linux for eclipse and windowbuilder; I added the -Djava.awt.headless=true into the eclipse.ini and that partually solved the "hang" problem cause before that I couldn't work with windowbuilder at all having re-size eclipse window after each new component adding or dnd to force repaint and make eclipse app un-hang; After I added the -Djava.awt.headless=true I can add graphics components quite well but still there is hang problem occurs on: - the very first gui component was added - a gui component was DnD-ed I said "the very first" gui component was added because it seems there is a code generation problem cause right after : - the very first gui component was added - I resize eclipse to force repaint and as a result un-hang - gui component related code was generated - all next gui components adding cause no hang effect - if I DnD conponent eclipse hangs again ...that's why I do suspect windowbuilder gui wusiwyg generation and code ganaration are not synched or similar... I'd really like to find out a workaround for this linux's x64 eclipse cause the same ecipse for windows xp pro x32 works fine...
