macOS 14.4 causes JVM crashes

&gt; 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.<p>This isn’t just any old thread triggering SIGKILL, it’s the JIT thread privileged to write to executable pages that is performing illegal memory accesses. That’s typically a sign of a bug, and allowing a thread with write access to executable pages to continue executing after that is a security risk.<p>But I know of other language runtimes that take advantage of installing signal handlers for SIGBUS&#x2F;SIGSEGV to detect when they overflow a page so they can allocate more memory, etc. This saves from having to do an explicit overflow check on every allocation. Those threads aren’t given privilege to write to executable memory, so they’re not seeing this issue…<p>So this sounds like a narrow design problem the JVM is facing with their JIT thread. This blog doesn’t explain why their JIT thread <i>needs</i> to make illegal memory accesses instead of an explicit check.

“The Java Virtual Machine […] leverages the <i>protected memory access signal mechanism</i> both for correctness (e.g., to handle the truncation of memory mapped files) and for performance.”<p>Where by “protected memory access signal mechanism”, they mean SIGBUS&#x2F;SIGSEGV, i.e., a segfault.<p>This is probably because the JVM is doing “zero cost access checks”, which is where you do the moral equivalent of:<p><pre><code> try { writeToFile() } catch(err) { if (err == SYSTEM_CRASH_IMMINENT) { changeFilePermissions() retry } } </code></pre> …because it’s faster than checking file permissions before every write. (It’s a common pattern in systems programming, so it’s not <i>quite</i> as crazy as it sounds.)<p>I guess my opinion on this is that if you write your program to intentionally trigger <i>and ignore</i> kill(10) &#x2F; kill(11) from the host OS, for the sake of a speed boost, you can’t really get too mad when the host OS gets fed up and starts sending kill(9) instead.<p>I also wonder what happens in the (extremely rare) case where the signal the JVM is trapping is a <i>real</i> segfault, and not an operating system signal.

&quot;The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update.&quot;<p>I wonder if Oracle really didn&#x27;t know beforehand.<p>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&#x2F; .disable-executable-page-protection). I wonder if Oracle has been ignoring them, satisfied with the signal-handler workaround, and Apple finally enforced their policy.<p>Apple also expects that developers deploying apps on MacOS that use Java have these entitlements configured on a per-app basis. Oracle likely objects that this is not really for the application developer to certify, since it&#x27;s pretty much out of their control.<p>In any case, I&#x27;m doubting Oracle&#x27;s release is the whole truth.

The main question now is why hasn&#x27;t it been exposed in pre-release 14.4. This could mean some very urgent and risky change got its way to the 14.4 release, or that the whole macos release process is broken and unstable.

Amazing that Apple introduced a breaking change in a .4 release. Probably a mistake?<p>Also amazing it wasn&#x27;t caught during the beta period.

&gt; <i>&quot;As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions.&quot;</i><p>I&#x27;m just a lowly JavaScript&#x2F;TypeScript&#x2F;PHP programmer, but what is the Very Good Reason that Java trying to access other processes&#x27; memory?

I just bought a MacBook Pro with the M3 Max chip and installed MATLAB R2023b. Sonoma 14.3 is in place. As a requirement, I had to also install Corretto 8. MathWorks only supports the Java 8 JRE included with Amazon Corretto 8. I am already having several problems in MATLAB with his new setup. Can I assume that updating to Sonoma 14.4 might very well cause even more problems? I really don&#x27;t understand any of this.

It is always funny to Me when Apple zealots come into threads blaming everyone but Apple that software broke. Complaining Java doesn’t follow Apple standards or some crap. Then 9 days later Apple issues a fix because they did indeed break it.

It seems highly unlikely that the macos people don&#x27;t test anything on the jvm during acceptance. It&#x27;s even more suspicious that this change didn&#x27;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&#x27;s razor, this seems like such an enormous oversight its hard for me to ascribe it to incompetence.

Another example for how preventing users from doing rollbacks is a terrible practice. Even if it&#x27;s not your application&#x27;s fault, users may have very good reasons to revert an update, if only temporarily.<p>This also bothers me on Android. Sometimes, an app update may break something and prevent me from using it. But Google doesn&#x27;t allow me to reinstall a previously published version from the Play Store. If I don&#x27;t have to (or can&#x27;t easily) do without that application until a fix might be released, my only option is to find an older release on some shady mirror site.

considering macOS is doing the right thing, shouldn&#x27;t the title read JVM crashes on macOS 14.4 ?

A gross and low performance option for now might be to run Java under Rosetta, but I’m saying that based on them saying that this is apple silicon specifically and processes under rosetta have a bunch of quirks to support intel semantics. This would allow you to work around this for now.<p>That said I’m curious what the exact scenario that leads to this is, I’m assuming it’s not common as you would expect it to have come up during betas and pre -release seeds.

14.4 also killed automated device enrollment in VMware&#x27;s workspaceone. We&#x27;re having to downgrade brand new MacBooks to 14.3 using configurator.

I wonder if it&#x27;s the same reason as why Civilization 6 stopped working on iPadOS 17.4. Did they change something deep in the kernel for DMA compliance?

Is the signals change in macOS likely to affect JIT-based systems other than the OpenJDK JVM?

Isn&#x27;t this just W^X?

Wait, they write to protected memory, and get killed.<p>:tripplefacepalm:<p>Somebody hire some engineers at Oracle.

macOS dark ages.<p>I wonder if we’re about to enter 4-5 years of macOS “dark ages”, due to Apple grappling with EU&#x2F;DMA.<p>Much like Microsoft in early 2000s, between IE&#x2F;lawsuit and grappling with internet security&#x2F;viruses. Windows XP, launched in 2001, was considered by most a great OS, didn’t have another good OS successor until 8-years later (Windows 7).

Apple and macOS is slowly becoming another Windows in terms of stability.<p>There was a HN post about a hashicorp founder using Linux within a vm on their mbp. Might adopt that same approach, if I can find the og post.

<p><pre><code> 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 </code></pre> If this affects so many versions of Java and nobody notices, is anyone even using Java on macOS?

Well, that’s why Apple forbids use of private APIs in the App Store apps. If you built all your tech stack on the foundation of some peculiar nondocumented platform’s behavior, don’t be surprised when this stack breaks.