macOS 14.4 causes JVM crashes

Original Article ↗ Hacker News Discussion ↗

A recent macOS 14.4 update on Apple silicon machines is causing Java applications—from Java 8 through early JDK 22 builds, including popular tools like IntelliJ and MATLAB—to crash due to a change in how the OS handles protected memory access. Developers debate whether Apple violated long‑standing POSIX expectations by turning what used to be recoverable SIGSEGV/SIGBUS faults into uncatchable SIGKILL signals, versus whether the JVM was relying too heavily on low-level behavior for performance. The incident fuels broader concern about Apple’s QA and stability, the lack of easy OS rollbacks, and where the responsibility lies between OS vendors and runtime implementers when kernel behavior changes.

Scope and Impact

  • macOS 14.4 on Apple silicon causes unexpected termination of JVM-based processes via SIGKILL instead of the previously handled signals (SIGSEGV/SIGBUS).
  • Affects Java 8 through early-access JDK 22 according to Oracle’s updated statement; earlier comments note evolving understanding (some initially thought 20/21 unaffected).
  • Reports of intermittent crashes in IntelliJ, Rider, RubyMine, Eclipse, MATLAB (via Corretto 8), and other JVM-based tools; frequency varies from “less than daily” to “hours of work before one crash.”
  • Many advise postponing upgrade to 14.4, especially for heavy Java/IDE users; those already on 14.3.x often choose to stay put.

Technical Behavior Change

  • macOS 14.4 changes how protected-memory violations are handled when a JIT-writing thread is involved: previously generated catchable signals, now often produce SIGKILL.
  • JVMs use deliberate protected-memory accesses for “zero-cost” checks (safepoints, GC, stack/heap growth, NPEs, mmap truncation handling).
  • Some note macOS documentation (e.g., mprotect) historically promised SIGSEGV/SIGBUS for protection violations, matching JVM assumptions.

POSIX / Standards Debate

  • One side: this breaks POSIX/UNIX expectations; segmentation violations should signal, not unconditionally kill, and changing this in a minor release is a kernel bug.
  • Other side: POSIX may not strictly forbid SIGKILL here, and the OS can terminate processes at will; compliance status is debated, with references to POSIX text but no consensus.

Security vs Compatibility

  • Security-focused view: killing a JIT thread that illegally writes to executable/protected memory is “doing the right thing” and reduces attack surface; using signals for this was always risky.
  • Compatibility-focused view: “don’t break userspace”; Java’s approach is standard systems practice across OSes, long-standing, and should not suddenly stop working.

Workarounds and Alternatives

  • Suggested temporary mitigations: run Java under Rosetta; avoid upgrading; use Linux (bare metal or VM) or Windows/WSL for development.
  • Questions raised about other JIT runtimes (e.g., JavaScript engines) and whether they’re similarly affected; unclear from thread.

Apple Process and Motivation

  • Many criticize Apple’s QA and release process: bug was absent in 14.4 betas but appeared in final, suggesting last-minute kernel changes.
  • Some speculate about stricter enforcement of JIT entitlements; others reject this and see it as a straightforward regression.
  • Later comments note Apple has shipped a follow-up fix, used as evidence that the breakage was indeed on Apple’s side.