Live data from Hacker News

macOS 14.4 causes JVM crashes

blogs.oracle.com

101–110 of 160 posts

Re: macOS 14.4 causes JVM crashes

#102
post #47

> macOS on Apple silicon processors (M1, M2, and M3) includes a feature which controls how and when dynamically generated code can be either produced (written) or executed on a per-thread basis. […] With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead. This isn’t just any old thread triggering SIGKILL, i…

As Linus famously said: Shut. Up. Don’t break userspace and then blame the user.

https://lkml.org/lkml/2012/12/23/75

Re: macOS 14.4 causes JVM crashes

#103
post #42

“The Java Virtual Machine […] leverages the protected memory access signal mechanism both for correctness (e.g., to handle the truncation of memory mapped files) and for performance.” Where by “protected memory access signal mechanism”, they mean SIGBUS/SIGSEGV, i.e., a segfault. This is probably because the JVM is doing “zero cost access checks”, which is where you do the moral equivalent of: try { writeToFile() } c…

> I also wonder what happens in the (extremely rare) case where the signal the JVM is trapping is a real segfault, and not an operating system signal.

Just an educated guess, but the JVM knows if a thread may expect a segfault at a given point or not. If no thread expects one, then I assume the segfault handler just writes out that a segfault happened with some useful info, and terminates the program. I mean, I’m sure about the effect as I have caused a JVM to segfault a couple of times with native memory, so it handles it as expected.

Re: macOS 14.4 causes JVM crashes

#104
post #89

"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update." I wonder if Oracle really didn't know beforehand. Apple has long been telling people (writing JITs) that to write to executable memory, they need the correct entitlements (com.apple.security.cs.allow-jit, allow-unsigned--executable-memory, and or/ .disable-executable-page-protection). I…

> Apple has long been telling people (writing JITs) that to write to executable memory, they need the correct entitlements (com.apple.security.cs.allow-jit, allow-unsigned--executable-memory, and or/ .disable-executable-page-protection). I wonder if Oracle has been ignoring them, satisfied with the signal-handler workaround, and Apple finally enforced their policy.

As far as I understand, that’s not the issue, the JIT itself works just fine. The JVM just uses the (quite common) trick that it doesn’t actually bound check everything, but let’s the hardware trigger an interrupt, expecting that to “bubble up” to the program at hand, so it can handle certain cases “for free”. This behavior was changed by apple, which causes issues.

Re: macOS 14.4 causes JVM crashes

#105
post #47

> macOS on Apple silicon processors (M1, M2, and M3) includes a feature which controls how and when dynamically generated code can be either produced (written) or executed on a per-thread basis. […] With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead. This isn’t just any old thread triggering SIGKILL, i…

It said it affected back to Java 8, so seems like this design has been there for a while, and since older versions are EOL, any Java level fix would not be patched back.

I wonder what that means for the Android SDK, which AFAIK requires an ancient Java8 runtime for the command line SDK tools on macOS.

Re: macOS 14.4 causes JVM crashes

#106

It seems highly unlikely that the macos people don't test anything on the jvm during acceptance. It's even more suspicious that this change didn't happen during the public beta. Is it possible that Apple is firing a warning shot at Java? Even as a huge fan of Hanlon's razor, this seems like such an enormous oversight its hard for me to ascribe it to incompetence.

> it seems highly unlikely that the macos people don't test anything on the jvm during acceptance.

I would be surprised if they do to be honest (Apple doesn't even catch obvious bugs in the new macOS settings panel, which really makes me wonder if there is a software QA process at all). For 3rd party apps they seem to rely on the software vendors to holler if a macOS update breaks their app. That's why the macOS prerelease versions exist. But since the bug wasn't present in the prerelease, affected vendors couldn't catch it. It's still a fuckup in Apple release process of course (which tbh also isn't surprising).

Re: macOS 14.4 causes JVM crashes

#107
post #47

> macOS on Apple silicon processors (M1, M2, and M3) includes a feature which controls how and when dynamically generated code can be either produced (written) or executed on a per-thread basis. […] With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead. This isn’t just any old thread triggering SIGKILL, i…

As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75

I feel like preventing illegal writes to protected memory is less "breaking user space" and more "protecting all space".

This is like arguing to allow the guy who can't drive and just pin-balls his way down the freeway bouncing of other cars, because to prevent him from driving would be to take away his personal freedoms.

Re: macOS 14.4 causes JVM crashes

#108
post #10
post #2

An issue introduced by macOS 14.4, which causes Java process to terminate unexpectedly, is affecting all Java versions from Java 8 to the early access builds of JDK 22 If this affects so many versions of Java and nobody notices, is anyone even using Java on macOS?

It's not terminating directly. I've seen a few IDE crashes this week, less than one per day, but since there's no log there's no easy way to determine it's related to a macOS change.

https://youtrack.jetbrains.com/issue/JBR-6802

The JetBrains team has already figured it out as well.

Re: macOS 14.4 causes JVM crashes

#109

It seems highly unlikely that the macos people don't test anything on the jvm during acceptance. It's even more suspicious that this change didn't happen during the public beta. Is it possible that Apple is firing a warning shot at Java? Even as a huge fan of Hanlon's razor, this seems like such an enormous oversight its hard for me to ascribe it to incompetence.

> it seems highly unlikely that the macos people don't test anything on the jvm during acceptance. I would be surprised if they do to be honest (Apple doesn't even catch obvious bugs in the new macOS settings panel, which really makes me wonder if there is a software QA process at all). For 3rd party apps they seem to rely on the software vendors to holler if a macOS update breaks their app. That's why the macOS prer…

What is the bug in the new System Settings panel?
Post reply on HN