Java 1.8.0_92, crash, боль, OS X и старые версии Eclipse
Invite pending
Экспериментальным путем установлено, что версия 1.8.0_92 под OS X El Capitan (проверено под 10.11.5 и 10.11.4) ведет себя нестабильно. Железо — MacBook Pro Retina Late 2013 (ME294).
Проявление — crash JVM
В версии 1.8.0_91 таких проблем не наблюдается. Проверено, в том числе, и на чистой инсталляции OS X (10.11.5).
Возможно, данная проблема характерна только при использовании «старых» версий Eclipse (Luna или Kepler).
В силу определенных обстоятельств, мне нужно использовать разные версии Eclipse. В данный момент я активно использую Luna — 4.4.2 и Kepler — 4.3.2. Переход на Mars успехом не завершился из-за глюка в Scala IDE (Eclipse уходит в бесконечный цикл индексации одного из scala jar'ов).
Весь этот «зоопарк» Eclipse'ов вполне себе успешно работал последние пару лет под OS X (Mavericks, Yosemite, El Capitan), а недавно началось… Я даже не отследил в какой момент моя вселенная дала трещину. Просто в одинпрекрасный момент Eclipse складывает «лапки» и говоит мол, не смог хозяин (crash и т.д.). Ну, скорее всего поставил глючный update OS X (было уже такое неоднократно) и новый update скоро все починит (поиск по данной проблеме ничего не дал. Возможно, моя проблема специфична только для определенного «железа»).
Crash происходил в разные моменты, но особенно часто в момент набора кода при вызове autocompletion'a Java кода (он же code assistant). При этом разовый вызов autocompletion'a проходил безболезненно, а вот 5-6 уже приводил практически к гарантированному «слету».
Ситуация стала совсем «невеселой», когда при добавлении конструктора в один из классов crash стал гарантированным (100% случаев). Как по мне — так это классический С-шный «заезд по памяти»: если модифицировать любой код этого же класса — все ок, а при попытке добавить конструктор — crash JVM. При этом, добавлять конструкторы в другие классы можно без проблем.
Потратив суммарно до 2х дней рабочего времени (благо backup'ы time machine были) я убедился, что проблема не связана ни с «битым» workspace'ом Eclipse, ни с «поломанной» OS X, ни с «глючными» plugin'ами Eclipse, ни с прочим ПО установленным на компьютере.
На чистой OS X, Eclipse Luna IDE for Java Developers (4.4.2) + Scala IDE + Countercloskwise и subversive+svnkit попытка добавить конструктор в этот злополучный класс приводит к ровно таким же последствиям — crash JVM (речь идет про JVM 1.8.0_92) и, при этом 1.8.0_91 все работает без проблем.
Для полноты картины, никакие специфические опции JVM 1.8.0_92 я не включал (ни CrashOnOutOfMemoryError, ни ExitOnOutOfMemoryError).
eclipse.ini:
Проявление — crash JVM
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fff956d501c, pid=29399, tid=0x000000000000160b
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libsystem_platform.dylib+0x501c] _platform_memmove$VARIANT$Haswell+0xfc
В версии 1.8.0_91 таких проблем не наблюдается. Проверено, в том числе, и на чистой инсталляции OS X (10.11.5).
Возможно, данная проблема характерна только при использовании «старых» версий Eclipse (Luna или Kepler).
В силу определенных обстоятельств, мне нужно использовать разные версии Eclipse. В данный момент я активно использую Luna — 4.4.2 и Kepler — 4.3.2. Переход на Mars успехом не завершился из-за глюка в Scala IDE (Eclipse уходит в бесконечный цикл индексации одного из scala jar'ов).
Весь этот «зоопарк» Eclipse'ов вполне себе успешно работал последние пару лет под OS X (Mavericks, Yosemite, El Capitan), а недавно началось… Я даже не отследил в какой момент моя вселенная дала трещину. Просто в один
Crash происходил в разные моменты, но особенно часто в момент набора кода при вызове autocompletion'a Java кода (он же code assistant). При этом разовый вызов autocompletion'a проходил безболезненно, а вот 5-6 уже приводил практически к гарантированному «слету».
Ситуация стала совсем «невеселой», когда при добавлении конструктора в один из классов crash стал гарантированным (100% случаев). Как по мне — так это классический С-шный «заезд по памяти»: если модифицировать любой код этого же класса — все ок, а при попытке добавить конструктор — crash JVM. При этом, добавлять конструкторы в другие классы можно без проблем.
Потратив суммарно до 2х дней рабочего времени (благо backup'ы time machine были) я убедился, что проблема не связана ни с «битым» workspace'ом Eclipse, ни с «поломанной» OS X, ни с «глючными» plugin'ами Eclipse, ни с прочим ПО установленным на компьютере.
На чистой OS X, Eclipse Luna IDE for Java Developers (4.4.2) + Scala IDE + Countercloskwise и subversive+svnkit попытка добавить конструктор в этот злополучный класс приводит к ровно таким же последствиям — crash JVM (речь идет про JVM 1.8.0_92) и, при этом 1.8.0_91 все работает без проблем.
Для полноты картины, никакие специфические опции JVM 1.8.0_92 я не включал (ни CrashOnOutOfMemoryError, ни ExitOnOutOfMemoryError).
eclipse.ini:
-startup
../../../plugins/org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.200.v20150204-1316
-product
org.eclipse.epp.package.java.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=256m
-Xms512m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Xverify:none
-server
-XX:+UseParallelGC