Live data from Hacker News

macOS 14.4 causes JVM crashes

blogs.oracle.com

91–100 of 160 posts

Re: macOS 14.4 causes JVM crashes

#91
post #85

Earlier quoted context omitted.

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.

If that document said something along the lines of "a SIGKILL may only be issued when XYZ" where XYZ didn't include this case then I'd agree with you. I don't see anything in there that says when a SIGKILL should be or, more importantly, should not be generated. So it seems perfectly valid for an implementation of an OOB memory access to generate a SIGKILL and a SIGSEGV. That SIGSEGV will never be seen because the SIGKILL can't be handled and will kill the process.

Re: macOS 14.4 causes JVM crashes

#92
post #85

Earlier quoted context omitted.

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

If that document said something along the lines of "a SIGKILL may only be issued when XYZ" where XYZ didn't include this case then I'd agree with you. I don't see anything in there that says when a SIGKILL should be or, more importantly, should not be generated. So it seems perfectly valid for an implementation of an OOB memory access to generate a SIGKILL and a SIGSEGV. That SIGSEGV will never be seen because the SI…

When kernel developers violate POSIX standards and break the JVM (and other applications not yet reported), it's a bug. Can't justify it or make excuses. Apple really fucked up here.

Linus Torvalds has a policy: "WE DO NOT BREAK USERSPACE!". You just don't release stupid changes like this in a kernel. I'm sure the team at Apple are not pleased that this bug got into production.

Re: macOS 14.4 causes JVM crashes

#93
post #11
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?

Maybe not a lot of macOS devs use Java, but a lot of Java devs use macOS

If you use a Jetbrains IDE you already use Java e.g. Webstorm and Pycharm.

Re: macOS 14.4 causes JVM crashes

#94
post #21

Earlier quoted context omitted.

It's not. It's trying to access unmapped or protected memory in its own process. Basically what its used for is to implement an 'if' that's super fast on the most likely path but super slow on the less likely path. It's not super clear what its being used for (this is often used for the GC but the fact that graal isn't affected means that likely still works). Possibly they are using this to detect attempts to use inl…

object.field is implemented as a direct load from the object; if the object turned out to be null, then the resultant signal is caught and turned into a NullPointerException

sorry, I didn't read the linked post closely enough—from my reading, this case is not one of the ones that was broken

Re: macOS 14.4 causes JVM crashes

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

macOS is trying to keep its systems safe. Can’t leave the back door open for few who were used to it.

Re: macOS 14.4 causes JVM crashes

#97
post #77
post #75

Earlier quoted context omitted.

Is it Apple or Oracle who should rightly be fixing this issue?

It's a bug in macOS and it breaks POSIX compliance. Oracle can develop a workaround but Apple should fix it in their next update.

bug? POSIX compliance? How?

Re: macOS 14.4 causes JVM crashes

#98
post #61

Amazing that Apple introduced a breaking change in a .4 release. Probably a mistake? Also amazing it wasn't caught during the beta period.

Apple has never been a follower of semantic versioning.

nitpick: Apple doesn't follow SemVer 2.0, but they do have a semantic versioning scheme, that is, the version components carry a certain semantic, it's just so that this semantic is different than the semantic defined by the SemVer 2.0 specification.

One can have any sort of semantic versioning that is not SemVer 2.0 compliant and still be useful, see e.g Rails or Ruby.

Even .Net assemblies are not SemVer 2.0 compliant: their pattern is maj.min.patch.build but SemVer 2.0 specifies that there can only be three conponents and build info must be behind a plus, like maj.min.patch+build

Re: macOS 14.4 causes JVM crashes

#99
post #77

Earlier quoted context omitted.

It's a bug in macOS and it breaks POSIX compliance. Oracle can develop a workaround but Apple should fix it in their next update.

bug? POSIX compliance? How?

When a kernel update breaks all JVM versions starting from Java 8, the kernel devs fucked up. Even worse when the breaking change is in the final production release only and not the beta release. Completely obvious that this is a bug.

Segmentation fault should trigger SIGSEV, not SIGKILL. They changed the behaviour of the kernel which broke the JVM and any other applications that are designed according to the POSIX standards. https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

Re: macOS 14.4 causes JVM crashes

#100

considering macOS is doing the right thing, shouldn't the title read JVM crashes on macOS 14.4 ?

Even if this was the right thing, they could / should have changed this behavior in a pre-release because that's exactly the kind of API change in the OS that will catch people off-guard. As another commenter wrote, I'd consider this either a serious flaw in Apples release process or they learned about some very dangerous vulnerability where the old behavior was abused and they decided that they rather annoy all users and vendors of Java software out there than tolerate the vulnerability in MacOS. But in this case I'd surmise that at least now Oracle would have been informed about this.
Post reply on HN