Community
Participate
Working Groups
Build ID: M20090211-1700 Steps To Reproduce: The error happens sproradicly at various occasions but frequently (about once a day). Please see "more information" More information: Eclipse 3.4 32Bit On Ubuntu Jaunty (previously Intrepid). VM: Sun 1.6.0_13 My UI freezes at various occasions. When I take a stack dump I always see the same scheme: - A GTK operation at class org.eclipse.swt.internal.gtk.OS is done - The operation calls org.eclipse.swt.internal.Lock.lock - Inside the lock there is an Object.wait() that never returns Most occasions happen somewhere inside the constructor of org.eclipse.swt.graphics.Image. Here is an example stack: java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa6fe89c0> (a org.eclipse.swt.internal.Lock) at java.lang.Object.wait(Object.java:485) at org.eclipse.swt.internal.Lock.lock(Lock.java:34) - locked <0xa6fe89c0> (a org.eclipse.swt.internal.Lock) at org.eclipse.swt.internal.gtk.OS.g_utf16_to_utf8(OS.java:2251) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.graphics.Image.<init>(Image.java:535)
We will need the full stacktraces (we need to see what threads). Likely the image is being created in the wrong thread.
There you are: java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa6da1db8> (a org.eclipse.swt.internal.Lock) at java.lang.Object.wait(Object.java:485) at org.eclipse.swt.internal.Lock.lock(Lock.java:34) - locked <0xa6da1db8> (a org.eclipse.swt.internal.Lock) at org.eclipse.swt.internal.gtk.OS.gdk_pixbuf_new(OS.java:3089) at org.eclipse.swt.graphics.Image.init(Image.java:963) at org.eclipse.swt.graphics.Image.<init>(Image.java:497) at de.innovationgate.eclipse.wgadesigner.WGADesignerPlugin.start(WGADesignerPlugin.java:159) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:984) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:370) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:446) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:399) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:387) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:315) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1274) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:867) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.core.internal.events.BuildManager.instantiateBuilder(BuildManager.java:788) at org.eclipse.core.internal.events.BuildManager.initializeBuilder(BuildManager.java:741) at org.eclipse.core.internal.events.BuildManager.getBuilder(BuildManager.java:480) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) The plugin that loads the image varies. This time it is one of our own. The code that loads the image: getImageRegistry().put(IMAGE_WGA_SERVER_START, new Image(Display.getCurrent(), getResourceAsStream("resources/icons/server_go.png"))); I will add more stacktraces as more hangs occur.
java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa6f49578> (a org.eclipse.swt.internal.Lock) at java.lang.Object.wait(Object.java:485) at org.eclipse.swt.internal.Lock.lock(Lock.java:34) - locked <0xa6f49578> (a org.eclipse.swt.internal.Lock) at org.eclipse.swt.internal.gtk.OS.g_utf16_to_utf8(OS.java:2251) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.graphics.Image.<init>(Image.java:535) at org.eclipse.jface.resource.URLImageDescriptor.createImage(URLImageDescriptor.java:162) at org.eclipse.jface.resource.ImageDescriptor.createImage(ImageDescriptor.java:227) at org.eclipse.jface.resource.ImageDescriptor.createImage(ImageDescriptor.java:205) at com.aptana.ide.core.ui.io.file.ProjectProtocolManager.<clinit>(ProjectProtocolManager.java:43) at com.aptana.ide.syncing.VirtualProjectSyncDecorator.decorate(VirtualProjectSyncDecorator.java:45) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:356) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:338) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:374) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:334) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Next time this happens can you attach an attachment of all of the thread stacks? I think you might have a situation similar to the one described in Bug 265028 but without seeing the rest of the threads in one place, it's hard to know for sure.
Created attachment 137477 [details] Stack Dump of current hang Took some time this time, but here is a complete stack dump of a current hang.
Created attachment 139170 [details] Yet another hang stackdump
Created attachment 139607 [details] Yet another one The frequency seems to be lower since I'm on JDK 1.6.0_13. But then again that just may be coincidence.
Created attachment 141994 [details] And yet another one - now on 64bit Eclipse I switched to 64bit Eclipse in the meantime (was working with 32bit Eclipse on 64bit Ubuntu before), to look if it makes a difference. Well, apparently not as the hangs still occur with similar stack traces.
Created attachment 142350 [details] Here we go again
Looks like it is gone with Eclipse Galileo.
Great - closing for now. Please reopen if you see it again.
Created attachment 235802 [details] Thread dump for the same problem with Kepler I reproduced this issue with Kepler. It happens only for certain workspaces, hence I guess it depends on something varying between them (i.e. the status of the files under version control... I see subclipse code within the call stack)
