Eclipse hangs randomly

[yurique]

Hi!

I'm having some problems using Swing Designer.

After installing Swing Designer Eclipse started to hang up randomly - on code completion in a code editor, after a property change in a designer (i.e. when I change a button's text), on refactorings, etc. After this I have to kill eclipse and restart it. And it happens frequently, almost after the first time I modify a property in designer.

Installation is a clean Galileo "Eclipse IDE for Java Developers" with Swing Designer installed via update site. The project is very simple with one application window and few panels and buttons.

[Eric Clayberg]

This not a problem we are familiar with, so please send us a test case and your complete Eclipse ".log" file.

You can also try running Eclipse in -debug -console mode and hit Ctrl+Break when it hangs to get a thread dump.

[astuckey]

Hi,

I am having the exact same issues, with a clean install of Eclipse Galileo and the latest Swing Designer from the update site.
Eclipse hangs randomly after the first class is looked at which is used by the designer plugin.

So far, the .log contains nothing, and only reports that eclipse didn't shut down correctly after the next restart.
Using the debug port, I can see that eclipse is running and the Instantiations plugins are active.

I managed to get the thread dump (kill -QUIT <pid> is the same as Ctrl-Break for the Linux users).

Regards,
Adam

[Eric Clayberg]

Does it hang with any class (like a brand new Swing JFrame subclass) or some specific classes?

[astuckey]

I have created 3 new classes, 1 x JFrame and 2 x JPanel - problem occurs in all three.
To reproduce:
- start eclipse
- double click on class to edit, opening in Source tab by default
- code proposals work ok
- select Design tab
- select Source tab
- code proposal now freezes eclipse

The seemingly random freezes I think are caused the by code proposal delay, if I am not quick enough typing it will freeze.
The ctrl-space will it to freeze instantly.

[Alexander.Mitin]

We cannot reproduce this using Ubuntu 8.10 x86_64.
According to the threads dump Eclipse waits for special gtk events in order to show Shell (see comments it Shell.setVisible() source).
Which Linux version you are using? Which window manager?

[astuckey]

I am running Fedora 11 x86_64 (2.6.29.5-191.fc11.x86_64) with Sun JDK 1.6.0_14 and using the GNOME desktop.
I can reproduce the problem the same way on another machine with the same configuration, as well as within Jboss Develop Studio 2.0 which is using Eclipse 3.4.

[astuckey]

I have installed and switched to the KDE desktop. So far I have been running ok for about an hour without a single freeze. As you mentioned, it looks like it is related to a GTK issue with the Gnome environment. It still looks like the issue is somehow triggered by the SwingDesigner plugin though, as eclipse runs ok until Designer parses the first class.

In the meantime I will kick on with KDE - let me know if you need me to provide more information, or if you want to put it down as a GTK issue.

[Eric Clayberg]

As you mentioned, it looks like it is related to a GTK issue with the Gnome environment. It still looks like the issue is somehow triggered by the SwingDesigner plugin though, as eclipse runs ok until Designer parses the first class.

If there is a serious bug in the OS window manager, editing a GUI class with Designer could certainly trigger it.

In order to get the perfect WYSIWYG display, Designer parses your GUI code and then instantiates the live GUI components in an off screen window and then takes a screen snapshot of that.

That last step does indeed cause interaction with the window manager. We have run into issues with rogue window managers before, so this is not unheard of.

[astuckey]

The strange thing is that it can display the generated GUI ok, it is as soon as you go back to the source view and trigger the content assist that the issue occurs. Thanks for your help - KDE it is then.

Cheers,
Adam

[Eric Clayberg]

If you trigger content assist in the normal Java editor, does the same thing happen.

What if you do it in the Swing Designer editor before switching to the Design view.

IOW, does it only happen after switching to the Design view?

[stupenrose]

I seem to be experiencing the same symptoms. In my case, eclipse becomes unresponsive (i.e. stops drawing screen updates), but there appears to be zero CPU usage. The following procedure illustrates the problem:

1) I open a class which extends JPanel
2) the class opens in the 'source' tab by default.
3) I place my cursor in between the parentheses of a zero-args JPanel() constructor invocation within the body of the class constructor, then press ctl-space
4) the normal auto-complete menu pops up
5) I then select the 'design' tab
6) the design mode shows up
7) I immediately select the 'source' tab again
8) I repeat step 3
9) the auto-complete menu does not display, and eclipse is unresponsive from this point forward.

My environment:

Code: Select all

stu@ursin:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"


Code: Select all

stu@ursin:~$ uname -a
Linux ursin 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linux


Code: Select all

stu@ursin:~$ cat bin/eclipse-galileo-jee/eclipse.ini
-startup
plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519
-product
org.eclipse.epp.package.jee.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m


[stupenrose]

Here is a bit of info regarding my eclipse setup.

[stupenrose]

Still more details:

Code: Select all

stu@ursin:~$ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)


Code: Select all

stu@ursin:~$ echo $JAVA_HOME
/usr/lib/jvm/java-6-sun


[Alexander.Mitin]

Please provide java threads dump (by 'kill -3 <pid>').