Freezing Eclipse 3.7 for Mac

Problem:

Eclipse 3.7 for Mac regularly, but not very deterministically, freezes (stops responding and the only way to communicate with it is 'Force Quit').

On this occasion, several critical bugs that have not yet been closed in the Eclipse buggyle have been written, the eldest being more than six months old.

Restarting the Eclipse ten times a day is not very exciting, so I had to be puzzled by finding a solution, which I would like to share with you, and at the same time, some techniques of its search.





Given:

Eclipse IDE for Java Developers + Eclipse Plug-in Development Environment + Google Plugin for Eclipse 3.7 + Subversive SVN Connectors + more on the little things.

In my case, I most often hung on saving (disabling Save actions could not).

At first I sinned on the GWT plugin - there was too much NPE from it in the log. Colleagues using linux or windows do not have this problem.



The standard step in exploring the causes of the problem: using jconsole to see what exactly is happening with the application.

To do this, run Eclipse in debug mode (eclipse -debug) and then connect to the Eclipse process using jconsole (start jconsole and select the process of your eclipse).

')

This was not enough: at the moment when the application was hanging, jconsole reported that the JVM was not responding.

In this case, we will try to collect information about the application while it responds, in the hope that we will be able to fix the death state. For these purposes, you can use the following script: there you can find a lot of ideas for finding deadlocks .

As indicated, the script was tested under linux, but it also works fine under mac.

Every second, the script saves to disk the stack stack list for all java processes in the application.



Next step: review suicide note.

In my case, I discovered the following two jobs:



"Worker-259" prio = 5 tid = 114889000 nid = 0x150919000 waiting for monitor entry [150917000]

java.lang.Thread.State: BLOCKED (on object monitor)

at org.eclipse.core.internal.watson.ElementTree.includes (ElementTree.javaimin27)

- locked <78c32e338> (a org.eclipse.core.internal.watson.ElementTree)

at org.eclipse.core.internal.resources.Workspace.getResourceInfo (Workspace.java:1768)

at org.eclipse.core.internal.resources.Resource.getResourceInfo (Resource.java:1235)

...

at org.eclipse.team.svn.ui.decorator.SVNLightweightDecorator.decorateModel (SVNLightweightDecorator.java:205)

at org.eclipse.team.svn.ui.decorator.SVNLightweightDecorator.decorate (SVNLightweightDecorator.java:195)

at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate (LightweightDecoratorDefinition.java:263)

at org.eclipse.ui.internal.decorators.LightweightDecoratorManager $ LightweightRunnable.run (LightweightDecoratorManager.java:81)

...



"Worker-258" prio = 5 tid = 111e97000 nid = 0x150816000 waiting for monitor entry [150815000]

java.lang.Thread.State: BLOCKED (on object monitor)

at org.eclipse.core.internal.watson.ElementTree.includes (ElementTree.javaimin27)

- locked <78c32e338> (a org.eclipse.core.internal.watson.ElementTree)

at org.eclipse.core.internal.resources.Workspace.getResourceInfo (Workspace.java:1768)

...

org.eclipse.team.internal.core.subscribers.SubscriberDiffTreeEventHandler.collectAll (SubscriberDiffTreeEventHandler.java:186)

at org.eclipse.team.internal.core.subscribers.SubscriberEventHandler.processEvent (SubscriberEventHandler.java.7017)

...



As you can see, one of them tried to update the decorators. Hence the idea of ​​solving the problem: wouldn’t we turn off the Label Decorators for SVN?

To do this, go to Preferences-> General-> Apperance-> Label Decorations and turn off SVN.

The solution is not great, but it works. As a result, without the Synchronization view, it’s not clear what to commit and what not; however, it seemed to me a lesser evil than the regular restart of Eclips.