Freezing Eclipse 3.7 for Mac
Problem:
Eclipse 3.7 for Mac regularly, but not very deterministic, freezes (stops responding and the only way to communicate with it is 'Force Quit').
On this occasion, several still not closed critical bugs have been written in the Eclipse bugzil, the elder for more than six months.
Restarting the eclipse ten times a day is not very exciting, so I had to be puzzled by finding a solution, which I want to share with you, and at the same time some techniques for finding it.
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, it most often hung on saving (disabling Save actions could not).
At first, the plugin sinned on GWT - there was too much NPE from it in the log. Colleagues using linux or windows do not have this problem.
The standard step in investigating the causes of the problem is to use jconsole to see what exactly is happening with the application.
To do this, start the 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 time the application crashed, jconsole reported that the JVM was not responding.
In this case, we will try to collect information about the application while it is responding, in the hope that we can fix the dying state. For these purposes, you can use the following script:there you can find many ideas for finding deadlocks .
As indicated, the script was tested under linux, but under mac it works fine too.
Every second, the script saves to disk a list of stack trac'ov for all java processes in the application.
The next step: analysis of a suicide note.
In my case, I found 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.java
∗27 ) - 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.eclternal. 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.java
∗27 ) - 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.andp.subsbersbersbersbersubs (SubscriberEventHandler.javahaps17)
...
As you can see, one of them tried to update the decorators. Hence the idea of solving the problem: is it possible to disable Label Decorators for SVN?
To do this, go to Preferences-> General-> Apperance-> Label Decorations and disable SVN.
The solution is not super, but it works. As a result, without a Synchronization view, you don’t understand what to commit and what not to; however, it seemed to me a lesser evil than regular restarting of Eclips.
Eclipse 3.7 for Mac regularly, but not very deterministic, freezes (stops responding and the only way to communicate with it is 'Force Quit').
On this occasion, several still not closed critical bugs have been written in the Eclipse bugzil, the elder for more than six months.
Restarting the eclipse ten times a day is not very exciting, so I had to be puzzled by finding a solution, which I want to share with you, and at the same time some techniques for finding it.
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, it most often hung on saving (disabling Save actions could not).
At first, the plugin sinned on GWT - there was too much NPE from it in the log. Colleagues using linux or windows do not have this problem.
The standard step in investigating the causes of the problem is to use jconsole to see what exactly is happening with the application.
To do this, start the 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 time the application crashed, jconsole reported that the JVM was not responding.
In this case, we will try to collect information about the application while it is responding, in the hope that we can fix the dying state. For these purposes, you can use the following script:there you can find many ideas for finding deadlocks .
As indicated, the script was tested under linux, but under mac it works fine too.
Every second, the script saves to disk a list of stack trac'ov for all java processes in the application.
The next step: analysis of a suicide note.
In my case, I found 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.java
∗27 ) - 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.eclternal. 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.java
∗27 ) - 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.andp.subsbersbersbersbersubs (SubscriberEventHandler.javahaps17)
...
As you can see, one of them tried to update the decorators. Hence the idea of solving the problem: is it possible to disable Label Decorators for SVN?
To do this, go to Preferences-> General-> Apperance-> Label Decorations and disable SVN.
The solution is not super, but it works. As a result, without a Synchronization view, you don’t understand what to commit and what not to; however, it seemed to me a lesser evil than regular restarting of Eclips.