Java падает на arm маках с macOS 14.4

Оригинал тут.

Из‑за бага в macOS 14.4 процесс Java машины может неожиданно завершиться. Это касается всех версий Джавы от 8 до 22. Нет никакого способа избежать или обойти этот баг. И нет простого способа откатить обновление macOS.

Этого бага не было в бета версиях macOS 14.4. Он появился только в релизе.

В macOS на М1, М2 и М3 Арм процессорах есть фича которая управляет тем как и когда исполняемый код генерируется и выполняется в каждом потоке.

В нормальном режиме работы JVM обращается к защищенным областям памяти. До версии 14.4 macOS в таких случаях отправляла процессу сигналы SIGBUS или SIGSEGV. Процесс мог сам решить что с ним делать и продолжать ли работу. В версии 14.4 когда процесс пытается писать в защищенную область памяти macOS отправляет ему SIGKILL. И процесс принудительно завершается.

JVM генерирет исполняемый код динамически. И использует защищенные области памяти для оптимизации и проверки корректности своей работы. Из‑за этого на macOS 14.4 JVM получает SIGKILL и завершается.

Предварительно скомпилированные нативные приложения GraalVM не подвержены этой проблеме. Но может возникнуть проблема со сборкой новых таких приложений.

Оракл предупредил своих клиентов, Эппл и сообщество OpenJDK об этой проблеме. Оракл рекомендует не обновлять ARM маки до версии 14.4 пока Эппл не починит баг.

Ссылочка на тикет.

@BugM
16.03.2024 21:31 UTC
Первоисточник

Комментарии

@wasd0
16.03.2024 16:40 UTC
+1

А в Graal предварительно скомпилированные до какой даты пока работают?

@BugM
16.03.2024 16:40 UTC
0

Как я понимаю любые. Но новые приложения на 14.4 уже могут не собраться.

@yrub
16.03.2024 22:49 UTC
+1

так а Graal же не обязательно компилировать в натив, это не единственный вариант ее использования, а просто опция, там jit по тестам работает на 20% быстрее, если оракл версия, а не комьюнити. Т.е. можно пользоваться как обычной vm.

Было бы правильней уточнить какая vm падает, а не просто абстрактная java, потому что есть hotspot, graal и даже OpenJ9 и это все совершенно разные vm.

16.03.2024 23:07 UTC
+4

Падает, всё что JIT. Не падает AOT без JIT, который компилиурет в натив.

@house2008
16.03.2024 17:16 UTC
+1

Jetbrains получается пропатчили свою джава раз не падает ?

@akazakow
16.03.2024 18:06 UTC
+1

У мен вчера два раза упал на разных маках. До обновления такого не было.

16.03.2024 19:15 UTC
+2

Я только 3 дня назад обновился до 14.4, по 10 часов в день запущена IDE, пока ни одного падения. Макбук про м1.

@Deeens
16.03.2024 17:33 UTC
+7

Как временное решение можно использовать вместо "нативной" aarch64 версию x64 под мак. В производительности теряете ~5% (IMHO), но не вылетает, а там ждем когда пофиксят.

@Sazonov
17.03.2024 08:50 UTC
+2

Как временное решение - да. Но x64 бинарники если и работают не сильно медленно, то вот запускаются намного дольше.

@DarthVictor
16.03.2024 17:47 UTC
+5

Кто-то похоже скопипастил код для iOS (в котором запрещена JIT-компиляция для пользовательских приложений) в macOS.

@PrinceKorwin
16.03.2024 19:09 UTC
+2

Скорее это просто обратная сторона унификации iOS и Mac OS. Всё больше частей делается общими.

17.03.2024 07:38 UTC
+1

И на Мак распространяются ограничения iOS просто потому что так удобнее было закодить?

17.03.2024 09:11 UTC
0

Или на Мак распространяются ограничения iOS просто потому, что эти ограничения делают систему более безопасной?

В любом случае без официального ответа мы не узнаем причину.

17.03.2024 10:34 UTC
0

Ну причина давно известна.

The first because we are an Apple, the second because f&ck you, that's why

17.03.2024 13:33 UTC
+6

An Apple lol

@vadimr
17.03.2024 07:53 UTC
0

Скорее это растёт из процессорной архитектуры Apple Silicon. Там есть нюансы с самомодифицирующимся кодом.

@timoxa_dev
16.03.2024 20:52 UTC
+8

Оракл рекомендует не обновлять ARM маки до версии 14.4 пока Эппл не починит баг.

Найс, разогнали штатных тестировщиков и теперь тестируют продукты на пользоввателях!

Ох вей, это же не Мелкомягкие, ну тогда понять и простить

@vadimr
17.03.2024 07:49 UTC
0

Ну Apple вообще не любит Java, поэтому, возможно, это их принципиальная позиция, и они считают, что это именно Oracle должна чинить баг. Собственно, формально поддержка Java не является частью основного дистрибутива macOS и устанавливается пользователем на свой страх и риск, хотя и из репозитория Apple.

17.03.2024 09:11 UTC
+3

На НАШ компьютер вы устанавливаете ВАШУ программу на свой страх и риск!

Вот до чего мы дожили. Фон Нейман с Тьюрингом обнявшись плачут.

17.03.2024 10:06 UTC
+1

Ну вообще во времена фон Неймана и Тьюринга так и было – программисты считались вспомогательным персоналом, налаживающим Компьютер.

17.03.2024 09:15 UTC
+5

Я бы не сказал, что Apple не любит Java. Наоборот Apple долгое время делала ставку на Java и очень сильно ей помогала. Например:

  1. поддержка 3D ускорения для Swing

  2. Ускорение запуска через shared rt.jar

  3. Apple предоставляла и сопровождала JNI прослойку ко всем функциям OS

  4. Обеспечивала бридж между Java приложениями и AppleScript

Но Java так и не стала популярной на Apple экосистеме и это точно не по причине того, что Apple не любило Java.

17.03.2024 17:49 UTC
0

Apple вообще не любит Java

Сильное заявление. У них много бэка на Java.

@sshikov
17.03.2024 11:53 UTC
0

А что, отключение JIT не помогает тоже? Не то чтобы я был уверен, что всегда можно отключить, но такие параметры имеются.

@Sap_ru
17.03.2024 15:49 UTC
0

Производительность упадёт в десятки раз (до сотни)раз.

17.03.2024 16:09 UTC
0

Это все понятно. Просто в статье написано, что способов обхода нет, в тоже время, если причина явно в JIT, а он отключается - это вызывает вопросы.

17.03.2024 18:41 UTC
+1

Замедление примерно в 100 раз. Типичная приложенька просто не запустится или не будет работать с такой производительностью. Поставить х86 jdk выглядит более хорошим временным решением.

@vitiok78
17.03.2024 12:42 UTC
0

У меня IDE от Jetbrains стали падать. Прискорбно...

К сожалению, дальнейшее усложнение систем с закрытым исходным кодом будет всё чаще вызывать подобные баги.

@Sap_ru
17.03.2024 15:55 UTC
+3

Падению общего уровня программистов и процессов разработки будет вызывать баги.
Например, в этом случае падать будет не только Java. Всё, что JIT будет падать. Возможно, что даже Python (должен был падать, но они, вроде, не успели в последнем релизе нативный AOT включить). Весь код, которые изменяет себя runtime будет падать. А такого кода много. Это было очевидно и предсказуемо. Но даже если ты пишешь ОС и при этом идиот, не понимающий, что и для чего в этой ОС используется, то на этот случай есть тестирование и предрелизные сборки. В которых ничего не падало, а поломали прямо в релизе без всякого тестирования. То есть не только идиот софт разрабатывал, а весь процесс разработки построен идиотами и никак толком не контролируется ещё одними идиотами, так как если идиот может неожиданно принять решение что-то крупное поломать в ОС без согласования и тестирования, то контроля нет. Сегодня динамический код запретили с бухты барахты, а завтра пароль "1234" на рута зашьют, так как тоже отличная идея.

17.03.2024 16:37 UTC
0

1234 - это верх безопасности по сравнению с тем, что у них было когда-то на High Sierra. Можно было ввести имя пользователя root без пароля, и, вуаля, ты в системе с неограниченными правами.

Если бы у системы был открытый исходный код, такое бы никогда в жизни не прошло в релиз

17.03.2024 18:31 UTC
0

с тем, что у них было когда-то на High Sierra.

Это еще что. Помнится на PowerPC у них была ОС которая вообще не давала защищенного режима приложениям. Т.е. любое приложение могло в любой момент времени залезть в память другого процесса. И ничего. Работало весьма стабильно и быстро. Эх. Были же времена когда не было хакиров :)

Если бы у системы был открытый исходный код, такое бы никогда в жизни не прошло в релиз

Очень сомневаюсь, что дело именно в открытости исходного кода.
В том же GRUB каких-только секурити дефектов не находят. Например был один когда для обхода пароля было достаточно ввести один любой символ из этого пароля.

Или когда пароль на скринсейвере банально ломали через переполнение буфера (нужно было ввести больше 255 символов). Скринсейвер крашился и открывал доступ к десктопу.

И все эти решения - OpenSource и баги эти жили годами.

17.03.2024 19:08 UTC
0

Баги будут всегда и везде. Пока есть люди, будут и баги. Вопрос в том, когда этот баг пофиксят. Они вообще могут его не фиксить либо отложить до осени. А о скольких серьезных багах, которые уже есть в системе, обнаружены ими, но ждут окна для их устранения, мы даже не знаем? А если такие баги обнаружены ими, то велика вероятность, что и хакеры о них прекрасно знают.

Моё личное мнение, которое я никому не навязываю: закрытое программное обеспечение менее безопасно, чем открытое. Security through obscurity не работает.

17.03.2024 18:59 UTC
0

Python интерпретирует части самой macOS, она не будет устанавливаться, если Python упадёт.

17.03.2024 19:50 UTC
0

Разные версии ведут по-разному, но в целом python активно движется в сторону бинарной трансляции. В MacOS может использоваться более старая версия и в неё могут быть подставленные доморощенные костыли.

17.03.2024 20:10 UTC
0

Apple высказывалась в том смысле, что питон в числе языков, которые с её стороны будут поддерживаться.

17.03.2024 20:13 UTC
0

Так тут дело не в том, что Java не поддерживается, а в том, что выкатили неоттестированое изменение. Там, вроде, уже писали, что это ошибка, которая будет исправлена.

@
18.03.2024 19:31 UTC
0
НЛО прилетело и опубликовало эту надпись здесь