Live data from Hacker News

macOS Sonoma 14.4 might break Java on your machine

appleinsider.com

11–20 of 271 posts

Re: macOS Sonoma 14.4 might break Java on your machine

#11

I find this hard to accept. Doesn't Apple do pre-release testing of their updates? How the release process looks like? News like these are the major reason why I apply updates only after long periods of waiting if anything blows up for others. Why companies use their userbase as testers?

[flagged]

Did you read Oracles post?

"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."

JVM generates code on the fly, which normal applications are not allowed to do. So java by definition receives special treatment from the OS, which OSX seem to have broken now.

Re: macOS Sonoma 14.4 might break Java on your machine

#12

I find this hard to accept. Doesn't Apple do pre-release testing of their updates? How the release process looks like? News like these are the major reason why I apply updates only after long periods of waiting if anything blows up for others. Why companies use their userbase as testers?

Strangely, the issue wasn't present in pre-release builds. I agree though, Apple's internal testing before final release should have picked this up.

Re: macOS Sonoma 14.4 might break Java on your machine

#14
post #11

Earlier quoted context omitted.

[flagged]

Did you read Oracles post? "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update." JVM generates code on the fly, which normal applications are not allowed to do. So java by definition receives special treatment from the OS, which OSX seem to have broken now.

It's not that Java has a special treatment, but all applications who "request it" are allowed (for example also JavaScript engines in browsers).

https://developer.apple.com/documentation/bundleresources/en...

Re: macOS Sonoma 14.4 might break Java on your machine

#15
> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process.

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

What is bizarre to me is that Oracle relied on receiving SIGSEGV as normal mode of operation. That should have been a hint where things are going, no?

Re: macOS Sonoma 14.4 might break Java on your machine

#16

> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process. > With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected m…

[deleted]

Re: macOS Sonoma 14.4 might break Java on your machine

#17

Maybe the Oracle blog post [1] would be a better link than the Apple Insider article, which says "The problem does not affect most typical Mac users, as Java was deprecated for the Mac back in 2012." [1] https://blogs.oracle.com/java/post/java-on-macos-14-4

Yeah, but all developers who are working with Java or JVM related languages or using JVM based tools like jetbrain's IDEs are affected. That's not "typical" but still many people.

Re: macOS Sonoma 14.4 might break Java on your machine

#18

> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process. > With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected m…

> What is bizarre to me is that Oracle relied on receiving SIGSEGV as normal mode of operation. That should have been a hint where things are going, no?

Not bizarre at all, this how the runtime has always operated, as anyone one who's ever attached a debugger to a Java process knows. The SIGSEGV handler is also responsible to handling NullPointerExceptions IIRC.

Re: macOS Sonoma 14.4 might break Java on your machine

#19

> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process. > With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected m…

It's documented and part of the interface for POSIX:

> Write attempts to memory that was mapped without write access, or any access to > memory mapped PROT_NONE, shall result in a SIGSEGV signal. > > References to unmapped addresses shall result in a SIGSEGV signal.

How a SIGSEGV can be handled by the program to continue execution normally need some OS specific code. For Linux there's also userfaultfd to suit this need better.

Re: macOS Sonoma 14.4 might break Java on your machine

#20
post #11

Earlier quoted context omitted.

[flagged]

Did you read Oracles post? "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update." JVM generates code on the fly, which normal applications are not allowed to do. So java by definition receives special treatment from the OS, which OSX seem to have broken now.

I did and also the bugreport.

https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860

It says that "It is also successful on the previous versions of Sonoma", no mention of EA.

In the bug report it says it's actually not reproducable with an eary access version of Java "It could not be reproduced on 23-ea+13, 22+36-2370"

TBF I'd rather not take Oracle's Product Managment's word for granted.

Post reply on HN