Проблема:
Эклипс 3.7 под Мак регулярно, но не очень детерминировано, замерзает (перестает реагировать и единственным способом общения с ним является 'Force Quit').
По этому поводу написано несколько до сих пор не закрытых critical багов в эклипсовской багзиле, старшему уже более полугода.
Перезапускать эклипс по десять раз на дню занятие не очень увлекательное, так что пришлось озадачиться нахождением решения, коим и хочу поделиться с вами, а заодно и некоторыми техниками его поиска.
Дано:
Eclipse IDE for Java Developers + Eclipse Plug-in Development Environment + Google Plugin for Eclipse 3.7 + Subversive SVN Connectors + еще по мелочи.
В моем случае чаще всего подвисал на сохранении (отключение Save actions не могло).
Поначалу грешил на GWT плагин — слишком уж много от него NPE в логе было. У коллег, использующих linux или windows подобной проблемы не возникает.
Стандартное шаг в исследовании причин проблемы: с помощью jconsole посмотреть что именно происходит с приложением.
Для этого запускаете эклипс в дебаг режиме (eclipse -debug) и затем подключаетесь к эклипсовскому процессу с помощью jconsole (запускаете jconsole и выбираете процесс вашего эклипса).
Этого оказалось недостаточно: в момент, когда приложение зависало, jconsole сообщал, что JVM не отвечает.
В таком случаем попытаемся собирать информацию о приложение пока оно отвечает, в надежде, что сможем зафиксировать предсмертное состояние. Для этих целей можно воспользоваться следующим скриптом: там же можно найти немало идей по поиску deadlock'ов.
Как указано, скрипт был протестирован под linux, но под mac'ом он тоже прекрасно работает.
Каждую секунду скрипт сохраняет на диск список stack trac'ов для всех java процессов в приложении.
Следующий шаг: анализ предсмертной записки.
В моем случае я обнаружил два следующих 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 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)
…
Как видим, один из них пытался обновлять декораторы. Отсюда идея решения проблемы: а не отключить ли нам Label Decorator'ы для SVN?
Для этого идем в Preferences->General->Apperance->Label Decorations и отключаем SVN.
Решение не супер, но работает. Как результат без Synchronization view не понять, что коммитить надо, а что нет; однако, оно мне показалось меньшим злом, нежели регулярный перезапуск Eclips'а.
Эклипс 3.7 под Мак регулярно, но не очень детерминировано, замерзает (перестает реагировать и единственным способом общения с ним является 'Force Quit').
По этому поводу написано несколько до сих пор не закрытых critical багов в эклипсовской багзиле, старшему уже более полугода.
Перезапускать эклипс по десять раз на дню занятие не очень увлекательное, так что пришлось озадачиться нахождением решения, коим и хочу поделиться с вами, а заодно и некоторыми техниками его поиска.
Дано:
Eclipse IDE for Java Developers + Eclipse Plug-in Development Environment + Google Plugin for Eclipse 3.7 + Subversive SVN Connectors + еще по мелочи.
В моем случае чаще всего подвисал на сохранении (отключение Save actions не могло).
Поначалу грешил на GWT плагин — слишком уж много от него NPE в логе было. У коллег, использующих linux или windows подобной проблемы не возникает.
Стандартное шаг в исследовании причин проблемы: с помощью jconsole посмотреть что именно происходит с приложением.
Для этого запускаете эклипс в дебаг режиме (eclipse -debug) и затем подключаетесь к эклипсовскому процессу с помощью jconsole (запускаете jconsole и выбираете процесс вашего эклипса).
Этого оказалось недостаточно: в момент, когда приложение зависало, jconsole сообщал, что JVM не отвечает.
В таком случаем попытаемся собирать информацию о приложение пока оно отвечает, в надежде, что сможем зафиксировать предсмертное состояние. Для этих целей можно воспользоваться следующим скриптом: там же можно найти немало идей по поиску deadlock'ов.
Как указано, скрипт был протестирован под linux, но под mac'ом он тоже прекрасно работает.
Каждую секунду скрипт сохраняет на диск список stack trac'ов для всех java процессов в приложении.
Следующий шаг: анализ предсмертной записки.
В моем случае я обнаружил два следующих 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 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)
…
Как видим, один из них пытался обновлять декораторы. Отсюда идея решения проблемы: а не отключить ли нам Label Decorator'ы для SVN?
Для этого идем в Preferences->General->Apperance->Label Decorations и отключаем SVN.
Решение не супер, но работает. Как результат без Synchronization view не понять, что коммитить надо, а что нет; однако, оно мне показалось меньшим злом, нежели регулярный перезапуск Eclips'а.
