Oracle Warns macOS 14.4 Can Cause Java to Terminate Unexpectedly

[RaceTripper]

To build on that -- this is the problem with Apple's dev team/model. They don't understand releases. Implicitly they operate under a rolling/subscription model update schema ignoring the cost on their users of broken releases and updates. Additionally since the fixes are always rolled into bigger updates, we don't really get a stable release until Apple's attention finally moves to the next release.

The idea behind a release candidate is that nothing changes between the release candidate and the released version except the build # and version text. If the RC breaks something major, you fix it and release another RC to make sure you didn't break anything major. I know that's old fashioned but here we are at macOS 14.4 -- the 4th subversion to the 23rd major release -- with new things breaking while major things stay broken release after release.

And this is where Apple lacks strategic alignment. If Apple's vision for the VisionPro is enterprise/hospital/etc sales, this won't fly. The reason why the iPhone made it into the enterprise is that Apple captured the consumer market first putting pressure on IT/etc from above and below. Given the terrible alternatives at the time, all they had to do then was throw in a few bones for the enterprise, and Blackberry, et all were dead. However, if Apple tries to skip that step while not addressing enterprise needs (like stability in the dev/release process), I bet their success in these markets will be middling at best.

Despite all that, it seems to me Apple doesn't even follow semantic versioning anyway. Introducing a breaking change in a minor release is a no-no, unless this was all unintentional. It's a show stopper bug in any case, and we should expect it corrected in a patch release (hopefully soon).

But I've seen OSS projects make breaking changes in patch releases so nothing surprises me about lack of adherence to semantic versioning anyway.

 

[bbeagle]

Despite all that, it seems to me Apple doesn't even follow sematic versioning anyway. Introducing a breaking change in a minor release is a no-no, unless this was all unintentional. It's a show stopper bug in any case, and we should expect it corrected in a patch release (hopefully soon).

Your comment makes no sense.

A minor release just means there are minor updates. Any update could cause a major problem.

Apple changed the signal that is returned when a process tries to use memory in protected regions of MacOS.
MacOS used to send a SIGBUS or SIGSEGV when protected memory was accessed - allowing the process to understand that it was using protected memory and avoid doing this. MacOS is now more pro-active and just sends a SIGKILL, which kills the process entirely.

The way the Java JDK is written is that it runs the user program and expects the OS to give it a SIGBUS or SIGSEGV if the program is writing protected memory. It then handles the issue itself by telling the program 'no' - and the program is still alive to continue functioning. Java could handle it a different way, and figure out what memory is protected, but it expects the OS to tell it. Now the MacOS isn't telling it, just killing the process.

Java could fix this by 'poking' into a memory location, and if the OS says it's okay - then continue to write memory, otherwise don't allow it. MacOS could fix this by going back to the same signal. Both teams are probably pouring over the technical and theoretical ideologies right now.

Whoever changed this thought it was a small change and didn't know this is the way Java worked. Now we know otherwise.

 

[seek3r]

This appears to be a bug in macOS that is crashing Java, not a bug in Java itself.



It may shock you to learn that much of macOS is still written in Objective-C (40 years old), C++ (45 years old), and C (55 years old).

You somehow quoted the wrong person, me, for both those quotes…

 

[RaceTripper]

Your comment makes no sense.

A minor release just means there are minor updates. Any update could cause a major problem.

Apple changed the signal that is returned when a process tries to use memory in protected regions of MacOS.
MacOS used to send a SIGBUS or SIGSEGV when protected memory was accessed - allowing the process to understand that it was using protected memory and avoid doing this. MacOS is now more pro-active and just sends a SIGKILL, which kills the process entirely.

The way the Java JDK is written is that it runs the user program and expects the OS to give it a SIGBUS or SIGSEGV if the program is writing protected memory. It then handles the issue itself by telling the program 'no' - and the program is still alive to continue functioning. Java could handle it a different way, and figure out what memory is protected, but it expects the OS to tell it. Now the MacOS isn't telling it, just killing the process.

Java could fix this by 'poking' into a memory location, and if the OS says it's okay - then continue to write memory, otherwise don't allow it. MacOS could fix this by going back to the same signal. Both teams are probably pouring over the technical and theoretical ideologies right now.

Whoever changed this thought it was a small change and didn't know this is the way Java worked. Now we know otherwise.

Do you understand what semantic versioning is? There's a pretty good Wikipedia article about it. If Apple wanted to change behavior to send SIGKILL instead of SIGBUS or SIGSEGV, that's fine but if it's a breaking change to previously documented behavior it doesn't belong in a minor release, period. They should deprecate the existing behavior in a minor release (and document they are doing it, and what should be done as an alternative), and make the breaking change in a major release. That's how semantic versioning works. If Apple doesn't follow that OK, but that's how it works if they do.

I'm a maintainer for an OSS JVM-based framework. We follow semantic versioning. You don't make breaking changes to existing behavior in a minor release.

 

[R3k]

Interesting. My audio system, using Logic Pro and creating scores for Netflix, has indeed been more unstable, but over the last year and a bit. More random crashes than the years previous. I guess a Lot of it due to developers catching up to Ventura and beyond, and I assumed mainly to the Native Instruments **** show. They've always been an unstable company and currently going through a merger, which includes Izotope (mentioned in this article) who actually dont use iLok frameworks themselves.

Haven't really noticed any extra bad behavior from the last update, though Un-do layers are bugged in RX10 as a plugin in logic. But maybe that was bad before the update, I dont know.

These are just musings as a professional audio user...but Apple, I dont think some major plugin devs have been able to keep up with you over the last couple of years, slow down or support them more. Users are getting caught in the middle.

 

[alchemistmuffin]

Here, I'll help you out with it anyway: "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."

Which meant Apple changed something on their end due to security patch up most likely and that Oracle needed to adapt to that. The fact that they shipped it as is means it’s not a bug but rather a feature.

They don’t seed multiple version of betas for nothing.

This is on Oracle’s fault here. They needed to fix it on their end.

 

[RaceTripper]

Which meant Apple changed something on their end due to security patch up most likely and that Oracle needed to adapt to that. The fact that they shipped it as is means it’s not a bug but rather a feature.

They don’t seed multiple version of betas for nothing.

This is on Oracle’s fault here. They needed to fix it on their end.

You are seemingly not a developer, and probably don't understand how things work. Right?

If Apple made the change AFTER all the betas and AFTER all the release candidates went out, and the problem was introduced in GM, how is this Oracle's (and all the other JVM implementers) fault?

This has been explained ad nauseam already in many above posts, and in the Oracle article posted originally. Do you really not understand what happened? Maybe you should should temper your discussion about software release cycles if you don't know how they work, and what happens when Apple (or anyone else) F's up the standard way of managing them.

 

[AdonisSMU]

Well, outside your little Apple-desktop-and-apps-world there is the great wide internet with big business servers, which are mainly driven by Java - surprise!
All developers for that well needed backends are now extremely handycapped - simple as that! Apple should asap provide a patch, or the fellow developers insisting of using a mac will be target for laughter from colleagues... 🤣

…but Java is still crap compared to some of the newer languages… but yeah probably best to stay out of Holy wars.

This is kind of Apple’s fault but stuff happens. Oracle’s posture around not caring about if Mac can run Java properly probably poisoned the well a little bit.

 

[adib]

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.

Somebody in kernel space broke user space. Somebody needs to put a Torvalds in there.

 

[RaceTripper]

Somebody in kernel space broke user space. Somebody needs to put a Torvalds in there.

Love this...Dear Apple. Is anybody home and answering the phones?

 

[Westside guy]

No way either one of those will die off as they are the most popular.

63% of developers use JavaScript, 30% of developers use Java.

Python is 49% - the only language in competition. Everything else is under 30%. Not sure why they list HTML/CSS, Bash Shell or SQL as programming languages. But, hey.

Most used languages among software developers globally 2023 | Statista

As of 2022, JavaScript and HTML/CSS were the most commonly used programming languages among software developers around the world, with more than 63.6 percent of respondents stating that they used JavaScript and just around 53 percent using HTML/CSS.

www.statista.com

I agree neither is going away... but I'm also compelled to point out that the javascript percentage is mixing use on both the server and client side.

Also, you can do some pretty significant programming in bash. Whether or not you should is another matter.

 

[Reason077]

Given Apple's history, I sure hope this was an oversight and not a shot over the bow.

Very unlikely that there's anything malicious going on here. Given the nature of the bug, I suspect that this was introduced as part of a hastily-implemented, last-minute, memory-management related security fix that wasn't properly tested.

 

[Reason077]

You somehow quoted the wrong person, me, for both those quotes…

Oops, my apologies! Edited and corrected.

 

[Reason077]

MacOS used to send a SIGBUS or SIGSEGV when protected memory was accessed - allowing the process to understand that it was using protected memory and avoid doing this. MacOS is now more pro-active and just sends a SIGKILL, which kills the process entirely.

The way the Java JDK is written is that it runs the user program and expects the OS to give it a SIGBUS or SIGSEGV if the program is writing protected memory.

No, this is not just "the way Java is written". The definition and behaviour of SIGBUS and SIGSEGV are part of the POSIX standard (IEEE 1003.1), which all modern Unix-like OSes including macOS are supposed to adhere to. Sending SIGKILL when SIGSEGV or SIGBUS are expected is broken, and it's a bug.

POSIX - Wikipedia

en.wikipedia.org

POSIX signals specification:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

 

[bsolar]

They don’t seed multiple version of betas for nothing.

The change was not in the betas, at least from what was reported.

This is on Oracle’s fault here. They needed to fix it on their end.

A breaking change is a breaking change, regardless of whether it is introduced by a new feature or a bugfix.

Anyone who has maintained software knows that breaking changes need to be properly documented and adequately communicated as software relying on the original behavior can break if the behavior is changed, regardless of the reason prompting the change.

Even in cases of bugs, software might have implemented logic that rely on the buggy behavior and they need to be informed to modify said logic.

This is a change of which signal is sent by the operating system and on top of that it switches to SIGKILL which cannot be handled by the process receiving it: it's a huge deal and quintessential breaking change in nature.

 

[RedWeasel]

A minor release just means there are minor updates. Any update could cause a major problem.

Apple changed the signal that is returned when a process tries to use memory in protected regions of MacOS.
MacOS used to send a SIGBUS or SIGSEGV when protected memory was accessed - allowing the process to understand that it was using protected memory and avoid doing this. MacOS is now more pro-active and just sends a SIGKILL, which kills the process entirely.

This is by no means a "minor update".

 

[bsolar]

A minor release just means there are minor updates.

Not if you are following semantic versioning, as it's good practice to do:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

This is clearly a change that makes incompatible API changes, so it should have been released in a MAJOR version.

 

[simty]

Oracle this week warned that the macOS 14.4 update released earlier this month for Macs can cause Java processes to "terminate unexpectedly."

In a blog post on Friday, Oracle's Senior Director of Product Management Aurelio Garcia-Ribeyro recommended that Apple silicon Mac users who rely on Java avoid updating to macOS 14.4 until the issue is resolved by Apple:The blog post and bug report include more technical details about the issue.

Oracle says it has notified Apple about the issue. Apple did not immediately respond to our request for comment about the matter.

Update: macOS 14.4 also has compatibility issues with audio plugins protected by PACE/iLok.

Article Link: Oracle Warns macOS 14.4 Can Cause Java to Terminate Unexpectedly

I believe this bug totally ruined my log planned-for online SQL coding-course last week

 

[H2SO4]

I love the naivety about Java. People literally have no idea where it is actually used.

That said I wish it'd die.

This. There are quite a few industrial applications that still rely on Java still.

 

[AlmightyKang]

No, this is not just "the way Java is written". The definition and behaviour of SIGBUS and SIGSEGV are part of the POSIX standard (IEEE 1003.1), which all modern Unix-like OSes including macOS are supposed to adhere to. Sending SIGKILL when SIGSEGV or SIGBUS are expected is broken, and it's a bug.

POSIX - Wikipedia

en.wikipedia.org

POSIX signals specification:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

Don't assume that POSIX is well defined or it is being used properly.

SIGBUS isn't well defined in context to mmap.

 

[Spike1999]

Wow so many people on here are completely ignorant about Java. It’s one of the most widely used programming languages. Android OS is mostly written in Java ffs.

 

[RedWeasel]

Wow so many people on here are completely ignorant about Java. It’s one of the most widely used programming languages. Android OS is mostly written in Java ffs.

What I find even funnier is that people have an attitude like "Apple is above Java, Apple has Swift" while completely ignoring that a good part of Apple's backend systems are probably written in Java.

 

[DaveMcM76]

Most used programming languages among developers worldwide as of 2023

For the ignorant Apple fans, here are the stats from the linked chart:
Java - 30.55%
Swift - 4.65%
Objective-C - 2.31%

The language I spend 90% of my day job using doesn't even make the list.... Progress OpenEdge.

 

[manofthematch]

That's not a reason to keep maintaining dinosaur tech. Where I work, most of our server side problems are caused by buggy java apps and applets. Java needs to die.

If your company has these problems and millions others don't have them with Java, your conclusion is that Java is the cause for the problems? Sure?

 

[RaceTripper]

If your company has these problems and millions others don't have them with Java, your conclusion is that Java is the cause for the problems? Sure?

Heh...I'd be interested in how they run Applets server-side. They executed in browsers on the client-side, but browsers no longer support them, and haven't for nearly a decade.