Community
Participate
Working Groups
Build Identifier: "building workspace" task hangs on 3% on eclipse startup. eclipse becomes "not responding" afterwards. Reproducible: Always Steps to Reproduce: Happened abruptly this morning. eclipse was working fine until last night that I left work. happens on startup before I do anything.
Created attachment 196615 [details] error message after force-quitting eclipse
After a few attempts it magically disappeared!
Next time when it happens please take a stack trace and attach it here. For details see http://wiki.eclipse.org/index.php/How_to_report_a_deadlock.
Created attachment 196714 [details] Thread Dump Thread Dump taken from VisualVm
Thread Dump attached.
It is happening again this morning! For the second day Eclipse becomes non-responsive when I start up in the morning to start work. Yesterday, after a few attempts, the problem disappeared. Will report if it is the case today too.
This looks like the infamous class loader deadlock.
The problem was very persistent, so I switched to 64bit version of JVM and eclipse, and so far so good!
It is unclear to me who is holding the classloader lock which the "main" thread is blocked on. I don't see any other suspect threads that look to be holding the class loader lock. It is possible the native VM could be holding the lock, but that can usually be detected by a call to ClassLoader.loadClassInternal. Perhaps the following portion of the stack on thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" is caused by the VM loading the class and the class loader is locked there. at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.hibernate.eclipse.jdt.ui.internal.HQLExpressionCompilerParticipant.isActive(HQLExpressionCompilerParticipant.java:56) If that is the case then this would be the infamous class loader lock that we can only truly fix by using Java 7. It looks like jobs may be involved also in this deadlock, but I could not tell what condition it is waiting on.
(In reply to comment #9) > If that is the case then this would be the infamous class loader lock that we > can only truly fix by using Java 7. Looks that way: "main" prio=6 tid=0x00369c00 nid=0xd88 waiting for monitor entry [0x003fe000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:468) - waiting to lock <0x112e4aa0> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) By the way, is there a central Wiki page or bug describing symptoms and what to do? I vaguely remember that there were few VM options that worked in some cases.
See my blog http://tomsondev.bestsolution.at/2011/03/17/equinox-hibernate-and-concurrency/ pointing to bug 212262
I'm moving this to Platform->Runtime because I still think there is something strange going on with the jobs here. Also, I know main is blocked on the class loader lock, but I still do not know who is locking it. I assume it is the native VM, but I cannot tell for sure here.
Happpening again in 64bit (latest Eclipse DL'd on Friday May 27) and 64bit JDK! Dump attached!
Created attachment 196861 [details] Thread Dump 2
Adding the following line to eclipse.ini seems to have fixed the problem for now: -vm C:/dev/tools/java/jdk1.6.0/bin/javaw
CORRECTION: please ignore my last comment, opened Eclipse this morning and the problem persists.
I believe I have identified the problem root: .../eclipse/plugins/org.hibernate.eclipse.jdt.ui_3.4.0.v20110215-1252-H31-GA.jar when I deleted this jar and restarted eclipse (eclipse -clean &), the deadlock did not happen again! Not sure if this is a random thing or this jar has always been the root of this evil...
I just encountered the same failure on java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 20.2-b06, mixed mode, sharing) Windows XP SP 3.
This occurred on Eclipse 3.7 Indigo Service Release 2.
Created attachment 216149 [details] Deadlock between JavaReconciler thread running BreakpointManager and 'main' thread running ProblemsLabelDecorator Deadlock encountered with Eclipse 3.7 Indigo service release 2
(In reply to comment #20) > Created attachment 216149 [details] > Deadlock between JavaReconciler thread running BreakpointManager and 'main' > thread running ProblemsLabelDecorator > > Deadlock encountered with Eclipse 3.7 Indigo service release 2 This is the infamous class loader deadlock and not a bug in Eclipse. This should not longer happen if you use JRE 7.
Couldn't we adjust our launch settings avoid this locking?
(In reply to comment #22) > Couldn't we adjust our launch settings avoid this locking? Not sure what you mean with that.
Passing "-XX:+UnsyncloadClass" to your vmargs avoids the deadlock - we are launching all our RCP-Applications with this switch
just looked once more and it is: -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass assuming you are talking about deadlock described in bug 212262
(In reply to comment #24) > Passing "-XX:+UnsyncloadClass" to your vmargs avoids the deadlock - we are > launching all our RCP-Applications with this switch This does not fix all cases (see e.g. bug 212262 comment 37) and it is a non-standard VM option.
It fixes not all of them but not unlikely this one - the eclipse.exe already checks for the VM-Type and e.g. sets the permgenspace so I don't see a reason it couldn't set those options if it detects hotspot as the vm, not?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
