Live data from Hacker News

macOS 14.4 causes JVM crashes

blogs.oracle.com

81–90 of 160 posts

Re: macOS 14.4 causes JVM crashes

#81
post #69

Earlier quoted context omitted.

It is not obvious to me that this breaks POSIX compatibility. The kernel may choose to signal a process with SIGSEGV on a memory protection violation but I can't find anything that suggests this is required . Last I checked, macOS formally maintains POSIX certification. Linux is not POSIX compliant, so I wouldn't use Linux as the measure of what is correct behavior under POSIX.

POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

2017? Wiki says macOS are UNIX 03 certified ;)

Re: macOS 14.4 causes JVM crashes

#82

Earlier quoted context omitted.

All system idiosyncrasies are APIs in the long run ;)

The change of a SIGSEGV to a SIGKILL, seriously?

It's Apple saying "What part of 'you cannot write to this page of memory don't you understand?"

Re: macOS 14.4 causes JVM crashes

#83
post #69

Earlier quoted context omitted.

It is not obvious to me that this breaks POSIX compatibility. The kernel may choose to signal a process with SIGSEGV on a memory protection violation but I can't find anything that suggests this is required . Last I checked, macOS formally maintains POSIX certification. Linux is not POSIX compliant, so I wouldn't use Linux as the measure of what is correct behavior under POSIX.

POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

Ah yes that is fairly clear, thanks, I was not able to find that. A plausible interpretation is that the kernel still reserves the right to terminate the process at anytime, including immediately after a general protection fault. Still an unexpected behavior, much like the Linux OOM killer.

Re: macOS 14.4 causes JVM crashes

#84

macOS dark ages. I wonder if we’re about to enter 4-5 years of macOS “dark ages”, due to Apple grappling with EU/DMA. Much like Microsoft in early 2000s, between IE/lawsuit and grappling with internet security/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).

It’s not at all like they didn’t have the time or the resources to deal with this.

I think we already saw some of this in particular with the recent bullshit they tried to pull with PWAs in iOS 17.4 that they were hoping to just let things break and were hoping that they could shift the blame and anger towards the EU instead.

Re: macOS 14.4 causes JVM crashes

#85
post #69

Earlier quoted context omitted.

POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

Maybe I'm being pedantic but as far as I can tell that document doesn't say when a SIGKILL can or can't be issued. So it seems like it would be valid to issue a SIGKILL at any time the kernel wants. Obviously, that's probably not users/programmers want but it seems to technically meet the specification you list.

It's not random. It is occurring in response to protected memory access. Violates the spec.

Re: macOS 14.4 causes JVM crashes

#86
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.

Re: macOS 14.4 causes JVM crashes

#87
post #62
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…

So MacOS is trying to be smart, changes their API, and now we're blaming the JVM for doing something we don't understand? At least they could have provided a path back to the old behavior.

That’s how MS works which leads to compatibility, but less stability. Historically with Apple, it’s their way or the highway. Less compatibility, but the OS is more stable.

Re: macOS 14.4 causes JVM crashes

#88
post #76
post #65

Earlier quoted context omitted.

".. is affecting all Java versions from Java 8 to the early access builds of JDK 22. There is no workaround available .." Do not update until Apple fixes the issue.

Isn’t this something Oracle will be fixing? Seems like it from other comments here.

No. Oracle will not fix jre8 because it's too old. Oracle will not fix corretto jre, because it's not theirs.

Re: macOS 14.4 causes JVM crashes

#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 wonder if Oracle has been ignoring them, satisfied with the signal-handler workaround, and Apple finally enforced their policy.

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's pretty much out of their control.

In any case, I'm doubting Oracle's release is the whole truth.

Post reply on HN