[innogate]

I’m experiencing hang situations while building the workspace on Eclipse 64bit 3.3.2 / MyEclipse 6.6 running on Ubuntu Intrepid. The build process does not continue while there is no CPU activity.

Using Visual VM I fetched a Thread Dump and found the following Stack Trace from a thread that I assume being responsible for the hang, because it does not move from the shown position and it is the only activity in the VM. It seems the hanging code belongs to the MyEclipse SQLExplorer:

java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
– waiting on <0x00007f5068e546a8> (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 <0x00007f5068e546a8> (a org.eclipse.swt.internal.Lock)
at org.eclipse.swt.internal.gtk.OS.pango_font_description_get_family(OS.java:9749)
at org.eclipse.swt.graphics.Font.getFontData(Font.java:190)
at com.genuitec.eclipse.sqlexplorer.core.SQLExplorerPlugin.initializeDefaultPreferences(SQLExplorerPlugin.java:323)
at com.genuitec.eclipse.sqlexplorer.core.SQLExplorerPlugin.<init>(SQLExplorerPlugin.java:151)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivation(PluginDescriptor.java:422)
at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDescriptor.java:370)

I can provide you with more stack trace information if needed.

[Loyal Water]

Does the problem persists in a new workspace as well?

Can you go to MyEclipse > Installation Summary > Installation Details and paste it here for me.

[innogate]

No, the problem appears sporadicly. Another start of the same workspace had no problems.

My Installation Details:
*** Date:
Dienstag, 25. November 2008 11.21 Uhr CET

** System properties:
OS=Linux
OS version=2.6.27-7-generic
Java version=1.6.0_07

*** MyEclipse details:
MyEclipse Enterprise Workbench
Version: 6.6.0
Build id: 6.6.0-20081015

*** Eclipse details:
Eclipse SDK

Version: 3.3.2
Build id: M20080221-1800

Eclipse Project SDK

Version: 3.3.3.r33x_r20080129-7M7J7LB-u3aphGW6o3_VmiVfGXWO
Build id: M20080221-1800

Eclipse Plug-in Development Environment

Version: 3.3.3.r33x_r20080129-7N7M5DQVIA_6oJsEFkEL
Build id: M20080221-1800

Eclipse Platform

Version: 3.3.3.r33x_r20080129-_19UEl7Ezk_gXF1kouft
Build id: M20080221-1800

Eclipse Graphical Editing Framework

Version: 3.3.2.v20080129
Build id: 20080221-1602

Eclipse RCP

Version: 3.3.3.r33x_r20080129-8y8eE9UEUWI6qujeED0xT7bc
Build id: M20080221-1800

Eclipse Java Development Tools

Version: 3.3.2.r33x_r20080129-7o7jE7_EDhYDiyVEnjb1pFd7ZGD7
Build id: M20080221-1800

Eclipse startup command=-data
/home/oliver/Dokumente/MEWorkspaces/wga_projects
-os
linux
-ws
gtk
-arch
x86_64
-showsplash
-launcher
/home/oliver/Apps/Eclipse-3.3/eclipse/eclipse
-name
Eclipse
–launcher.library
/home/oliver/Apps/Eclipse-3.3/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.3.R33x_v20080118/eclipse_1023.so
-startup
/home/oliver/Apps/Eclipse-3.3/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20080118.jar
-exitdata
2830018
-vm
/home/oliver/Apps/Java/sun-jdk1.6.0_07/bin/java

[Loyal Water]

Another start of the same workspace had no problems.

The problem has been resolved in the same workspace? Did you switch to a new workspace and check?

[innogate]

Yes. Checked it with the original and another workspace. Seems to be some kind of timing issue.

Im irritated by the fact that the thread dump claims that the thread already owns monitor 0x00007f5068e546a8 while deeper in the call hierarchy he seems to be again waiting for it. Is this a normal situation or what does that mean?

[Riyad Kalla]

innogate,

We don’t officially support MyEclipse on 64-bit Eclipse or running with a 64-bit VM — but a good handful of our users are using it that way anyway and haven’t reported this. I noticed part of the stack trace was calling down into Pango — double-check that there isn’t a GTK update available for your platform AND try updating to 1.6.0_11 to see if the lockup in the native call stops happening… I’ve seen that improve with an update before a few times.

[innogate]

Haven’t had that problem in a time. Nevertheless, I think I will migrate to 32Bit-Eclipse with Eclipse 3.4/MyEclipse 7 so we have an officially supported platform. If the problem reoccurs I will try updating to 1.6.0_11. Till then, thanks for your help!

[Author]

Posts