Freezing Eclipse 3.7 for Mac
Problem:
Eclipse 3.7 under Mac regularly, but not very deterministic, freezes (stops responding and the only way to communicate with him is by 'Force Quit').
On this occasion, written a few still have not closed critical bugs in eclipseuml Basile, senior for more than six months.
Restarted Eclipse a dozen times a day not very exciting, so I had to be concerned with finding a solution, and I want to share with you, but at the same time and 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, it most often freezes on save (turn off Save actions could not).
At first sinned on GWT plugin — too much NPE was in the log. Colleagues using linux or windows such problems do not arise.
A standard step in the study of the causes of the problem: using jconsole to see what is happening with the application.
To do this, start Eclipse in debug mode (eclipse -debug) and then connect to EclipseCon the process using jconsole (jconsole and choose start process your Eclipse).
It was not enough: at a time when the app hangs, with jconsole reported that the JVM is not responding.
In this case try to collect information on the application until it meets, in the hope that we will be able to fix a dying condition. For this purpose you can use the following script: there you can find a lot of ideas on search deadlock's.
As indicated, the script has been tested under linux, but under Mac om it also works fine.
Every second the script saves to disk the list of stack trac's for all java processes in the application.
The next step: an analysis of suicide notes.
In my case I found two the following job:
"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:527)
— 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 the 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.java:527)
— 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:317)
...
As you can see, one of them tried to refresh decorators. Hence the idea of solving the problem and not disable if we Label Decorator's for SVN?
To do this go into Preferences->General->Apperance->Label Decorations SVN and disable.
The solution is not super, but it works. As a result, without Synchronization view do not understand that committing is necessary and what is not; however, it seemed to me a lesser evil than a regular restart Eclips'.
Article based on information from habrahabr.ru
Eclipse 3.7 under Mac regularly, but not very deterministic, freezes (stops responding and the only way to communicate with him is by 'Force Quit').
On this occasion, written a few still have not closed critical bugs in eclipseuml Basile, senior for more than six months.
Restarted Eclipse a dozen times a day not very exciting, so I had to be concerned with finding a solution, and I want to share with you, but at the same time and 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, it most often freezes on save (turn off Save actions could not).
At first sinned on GWT plugin — too much NPE was in the log. Colleagues using linux or windows such problems do not arise.
A standard step in the study of the causes of the problem: using jconsole to see what is happening with the application.
To do this, start Eclipse in debug mode (eclipse -debug) and then connect to EclipseCon the process using jconsole (jconsole and choose start process your Eclipse).
It was not enough: at a time when the app hangs, with jconsole reported that the JVM is not responding.
In this case try to collect information on the application until it meets, in the hope that we will be able to fix a dying condition. For this purpose you can use the following script: there you can find a lot of ideas on search deadlock's.
As indicated, the script has been tested under linux, but under Mac om it also works fine.
Every second the script saves to disk the list of stack trac's for all java processes in the application.
The next step: an analysis of suicide notes.
In my case I found two the following job:
"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:527)
— 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 the 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.java:527)
— 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:317)
...
As you can see, one of them tried to refresh decorators. Hence the idea of solving the problem and not disable if we Label Decorator's for SVN?
To do this go into Preferences->General->Apperance->Label Decorations SVN and disable.
The solution is not super, but it works. As a result, without Synchronization view do not understand that committing is necessary and what is not; however, it seemed to me a lesser evil than a regular restart Eclips'.
Комментарии
Отправить комментарий