Community
Participate
Working Groups
Build Identifier: 20110615-0604 Eclipse opens, and a second or two later the secure storage dialog pops up and locks up (i.e. you can't type in anything, it just hangs), making everything unresponsive. A workaround (unacceptable, as a lot of workspace information is lost) for now is to delete the .metadata/.plugins. I've attached a thread dump Reproducible: Sometimes
Created attachment 201583 [details] A thread dump of eclipse at the time of the hang
Created attachment 201586 [details] Relevant eclipse log
This is a weird stack. Does it happen on Eclipse 4.1 or 3.7 or 3.6 ? Tom, does this look like the class-loading issue to be fixed by Java 7? "main" prio=10 tid=0x00007faec0006800 nid=0x7dc9 waiting for monitor entry [0x00007faec6aaa000] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:477) - waiting to lock <0x00007fae417361e0> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
(In reply to comment #3) > This is a weird stack. Does it happen on Eclipse 4.1 or 3.7 or 3.6 ? > > Tom, does this look like the class-loading issue to be fixed by Java 7? > > > "main" prio=10 tid=0x00007faec0006800 nid=0x7dc9 waiting for monitor entry > [0x00007faec6aaa000] > java.lang.Thread.State: BLOCKED (on object monitor) > at > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:477) > - waiting to lock <0x00007fae417361e0> (a > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) This is happening with Indigo, I've also seen it with 3.6 and 3.5, though I don't have the thread dumps from those versions.
(In reply to comment #3) > This is a weird stack. Does it happen on Eclipse 4.1 or 3.7 or 3.6 ? > > Tom, does this look like the class-loading issue to be fixed by Java 7? > Yes it does. I am marking as dup of bug212262. This type of deadlock can only be handled by the framework if running on Java 7 or later. I did not analyze the team code. There could be something the team bundle(s) are doing in their activator that increases the window for this hang to happen. It seems there is some job running in the background that gets initiated before the activator of the team bundle is able to finish starting? If that is the case then perhaps the job initiation/running can be delayed until later. *** This bug has been marked as a duplicate of bug 212262 ***
I have identical symptoms but don't see anything indicating a classloader deadlock in my stacktrace. This is from Helios. (See attachment.)
Created attachment 203702 [details] Eclipse Helios stack dump on hang.
I also found a discussion of this same problem on Stackoverflow (http://stackoverflow.com/questions/2621081/eclipse-galileo-not-responding-ubuntu-64-bit) with a slightly better workaround than is mentioned above. Simply delete ~/.eclipse/org.eclipse.equinox.security/secure_storage resulting in less data loss.
