:tripplefacepalm:
Somebody hire some engineers at Oracle.
101–110 of 160 posts
:tripplefacepalm:
Somebody hire some engineers at Oracle.
> 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…
“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…
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.
"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…
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.
> 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.
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.
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).
> 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
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.
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.
The JetBrains team has already figured it out as well.
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…
Wait, they write to protected memory, and get killed. :tripplefacepalm: Somebody hire some engineers at Oracle.