14.4 also killed automated device enrollment in VMware's workspaceone. We're having to downgrade brand new MacBooks to 14.3 using configurator.
macOS 14.4 causes JVM crashes
111–120 of 160 posts
Re: macOS 14.4 causes JVM crashes
#112Earlier quoted context omitted.
As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75
I feel like preventing illegal writes to protected memory is less "breaking user space" and more "protecting all space". This is like arguing to allow the guy who can't drive and just pin-balls his way down the freeway bouncing of other cars, because to prevent him from driving would be to take away his personal freedoms.
There was no conceivable version of a road system where that behavior would ever be okay. However, it's not only conceivable but, apparently standard practice in systems programming, to "Try and Fail" instead of "Only Proceed if allowed".
So, if we want a tortured metaphor what JVM is doing is like trying to pass a turnstile to see if the pass is still valid so that on the happy path it saves the extra check. Now Apple decided that instead of just showing a red X and letting you buy a new pass, in the future you get shot in the back of the head if you try with an invalid pass.
Re: macOS 14.4 causes JVM crashes
#113> 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…
As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75
Linux did break adobe flash when it used memmove like memcopy after fixing a kernel bug. Can't think of any other examples though.
Re: macOS 14.4 causes JVM crashes
#114It 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.
It's not a problem that breaks all JVM based software instantly. So maybe Apple tests but not long enough to trigger this issue.
I really don't know what Apple would be 'warning' against. Don't use Java? There are tens of thousands of business and development tools depending on the JVM. Blocking Java would diminish the value of macOS tremendously and doing so without warning would open Apple up to lots of lawsuits.
Re: macOS 14.4 causes JVM crashes
#115It 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.
It's not a problem that breaks all JVM based software instantly. So maybe Apple tests but not long enough to trigger this issue. I really don't know what Apple would be 'warning' against. Don't use Java? There are tens of thousands of business and development tools depending on the JVM. Blocking Java would diminish the value of macOS tremendously and doing so without warning would open Apple up to lots of lawsuits.
>It's not a problem that breaks all JVM based software instantly.
Do you know how long it takes to reproduce? The OP was light on details here. I assume that a memory access issue with the JIT would pop up pretty quickly, though.
Re: macOS 14.4 causes JVM crashes
#116Apple and macOS is slowly becoming another Windows in terms of stability. There was a HN post about a hashicorp founder using Linux within a vm on their mbp. Might adopt that same approach, if I can find the og post.
Windows, as a kernel itself and by extension as a server, is very resilient stable to a point that there is a Windows NT 4 machine of a certain railroad control system still running continuously for 14 years without any restarts. It even still reboots back without problem in disastrous cases such as power loss due to hurricane or earthquake. Trust me, it is made by Dave Culter, it, just, works.
It is really the client facing side of Windows that really sucks, (warning: explicitly strong language) such as having really shitty software known as Office, like god why Word and not Latex, and why spreadsheet when we have database that we can query efficiently? Or not being able to have multi-user RDP session due to Microsoft having licensing dispute with Citrix about 20-ish years ago (fuck you Citrix, you asshole!). Or why do I have to do a lot of hoops and install a lot of "C++ redistributable" for running some antique software? Or why do I have to jump through a lot of group policy simply to enable WinRM and get remote powershell management?
Either way, I'm typing this on a Windows 11 desktop with WSL2 on. The hybrid experience is incredible, unless you need some performance critical app (WSL2 is in general slower than bare metal Windows and bare metal Linux itself, of course, except in machine learning).
Things like 9P to cross the Window file system access also introduced a lot of pain such as permission control because Windows does not have a POSIX-like permission system, like instead of having a simple 2 bytes that split into 3 octal number (there is a reason it is maxed out at 777), you have an incredibly sophisticated, capability and token-based access control system dated almost 30 years ago that Linux doesn't even have back in the day! But that pile of shit is now full of bugs and exploits such as token/handle duplication. (oh yes I'm talking about black hat territory as I also do some red team CTF regarding these stuff)
Re: macOS 14.4 causes JVM crashes
#117Earlier quoted context omitted.
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.
They may not fix it, but my understanding is they are relying on undocumented features and that's always a crap shoot. My company does low-level language stuff and we've been burned like this, too. We decided not to trade performance for compatibility in the last decade or two.
EDIT: maybe not undocumented, but undefined behavior?
Re: macOS 14.4 causes JVM crashes
#118Earlier quoted context omitted.
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.
Does not seems stable, when all Java based applications are crashing.
Re: macOS 14.4 causes JVM crashes
#119Earlier quoted context omitted.
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 s…
right, seems like sort of a no brainer that if a minor version bump of an OS completely breaks JDK8, that’s on the OS developer.
Re: macOS 14.4 causes JVM crashes
#120Earlier quoted context omitted.
As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75
Linux did break adobe flash when it used memmove like memcopy after fixing a kernel bug. Can't think of any other examples though.
Well, everyone breaks Adobe Flash... that's the whispered exception at the end of the rule: "don't break userspace and then blame the user (unless that user is Adobe Flash... F--- Adobe Flash)" ;P.