8 ms·

macOS 14.4 causes JVM crashes

235 points by kingds 3y ago

sunshinerag 3y ago
considering macOS is doing the right thing, shouldn't the title read JVM crashes on macOS 14.4 ?
- metanonsense 3y ago
  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.
DuskHorizon 3y ago
Well, that’s why Apple forbids use of private APIs in the App Store apps. If you built all your tech stack on the foundation of some peculiar nondocumented platform’s behavior, don’t be surprised when this stack breaks.
- bhawks 3y ago
  This is not an API. It's the handling of writes to memory the process has protected. In the past this would generate a signal the process could handle and recover from. Now it generates a sigkill which is uncatchable / unrecoverable from. These behaviours have been historically well documented.
  - DuskHorizon 3y ago
    All system idiosyncrasies are APIs in the long run ;)
    - fifteen1506 3y ago
      The change of a SIGSEGV to a SIGKILL, seriously?
      - DuskHorizon 3y ago
        And, why not? macOS is Apple’s IP and they have all rights to do with it as they want. Buy the way, Chrome/Node.js JavaScript engine uses JIT compilation too. Are they affected?
        samus 3y ago
        This breaks POSIX compatibility, which is basically saying FU to how a lot of developers expect to interact with an operating system for decades now.
        jandrewrogers 3y ago
        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.
        xcv123 3y ago
        POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...
        kmiller68 3y ago
        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.
olliej 3y ago
A gross and low performance option for now might be to run Java under Rosetta, but I’m saying that based on them saying that this is apple silicon specifically and processes under rosetta have a bunch of quirks to support intel semantics. This would allow you to work around this for now. That said I’m curious what the exact scenario that leads to this is, I’m assuming it’s not common as you would expect it to have come up during betas and pre -release seeds.
- grodriguez100 3y ago
  > I’m assuming it’s not common as you would expect it to have come up during betas and pre -release seeds. The article specifically says that the issue was not present in early access releases, so it was not possible to discover it before the actual release.
fwlr 3y ago
“The Java Virtual Machine […] leverages the protected memory access signal mechanism both for correctness (e.g., to handle the truncation of memory mapped files) and for performance.” Where by “protected memory access signal mechanism”, they mean SIGBUS/SIGSEGV, i.e., a segfault. This is probably because the JVM is doing “zero cost access checks”, which is where you do the moral equivalent of: try { writeToFile() } catch(err) { if (err == SYSTEM_CRASH_IMMINENT) { changeFilePermissions() retry } } …because it’s faster than checking file permissions before every write. (It’s a common pattern in systems programming, so it’s not quite as crazy as it sounds.) I guess my opinion on this is that if you write your program to intentionally trigger and ignore kill(10) / kill(11) from the host OS, for the sake of a speed boost, you can’t really get too mad when the host OS gets fed up and starts sending kill(9) instead. I also wonder what happens in the (extremely rare) case where the signal the JVM is trapping is a real segfault, and not an operating system signal.
- dzaima 3y ago
  This isn't about files, this is about plain pages of RAM[0]. It is a basic CPU operation to trap on unmapped pages, and OSes rightfully expose this useful feature (in addition to using it themselves), allowing processes to do many things, from lazily-computed memory regions to removing significant amounts of overhead doing a thing the CPU will inevitably do itself anyway. I believe the "the truncation of memory mapped files" section is for when the Java process memory-maps a file (as Java provides memory-mapping operations in its standard library, and probably also uses them itself), and afterwards some other unrelated process truncates the file, resulting in the OS quietly making (parts of) the mappings inaccessible. Here the process couldn't even check the permissions before reading (never mind how utterly hilariously inefficient that would be, defeating the purpose of memory-mapping) as the mappings could change between the check and subsequent read anyway. [0]: https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860, "I've managed to narrow this down to this small reproducer:" section
  - fwlr 3y ago
    You are of course completely correct. However, I still stand by my pseudocode - I claim that it will give a fairly accurate impression of the basic concept of zero-cost access checks to a reader who isn’t familiar with low-level systems programming. (That said, I have updated my comment to make it clear it’s more of a metaphor than a literal description.)
riscy 3y ago
> 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, it’s the JIT thread privileged to write to executable pages that is performing illegal memory accesses. That’s typically a sign of a bug, and allowing a thread with write access to executable pages to continue executing after that is a security risk. But I know of other language runtimes that take advantage of installing signal handlers for SIGBUS/SIGSEGV to detect when they overflow a page so they can allocate more memory, etc. This saves from having to do an explicit overflow check on every allocation. Those threads aren’t given privilege to write to executable memory, so they’re not seeing this issue… So this sounds like a narrow design problem the JVM is facing with their JIT thread. This blog doesn’t explain why their JIT thread needs to make illegal memory accesses instead of an explicit check.
- LadyCailin 3y ago
  It said it affected back to Java 8, so seems like this design has been there for a while, and since older versions are EOL, any Java level fix would not be patched back.
  - flohofwoe 3y ago
    I wonder what that means for the Android SDK, which AFAIK requires an ancient Java8 runtime for the command line SDK tools on macOS.
    - saurik 3y ago
      They now seem to work with Java 11.
    - vbezhenar 3y ago
      Java 8 is not EOL.
ivan_gammel 3y ago
I wonder if it's the same reason as why Civilization 6 stopped working on iPadOS 17.4. Did they change something deep in the kernel for DMA compliance?
INGSOCIALITE 3y ago
[flagged]
zx8080 3y ago
The main question now is why hasn't it been exposed in pre-release 14.4. This could mean some very urgent and risky change got its way to the 14.4 release, or that the whole macos release process is broken and unstable.
8crazyideas 3y ago
I just bought a MacBook Pro with the M3 Max chip and installed MATLAB R2023b. Sonoma 14.3 is in place. As a requirement, I had to also install Corretto 8. MathWorks only supports the Java 8 JRE included with Amazon Corretto 8. I am already having several problems in MATLAB with his new setup. Can I assume that updating to Sonoma 14.4 might very well cause even more problems? I really don't understand any of this.
- xcv123 3y ago
  ".. 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.
  - ls612 3y ago
    Is it Apple or Oracle who should rightly be fixing this issue?
    - xcv123 3y ago
      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.
      - sunshinerag 3y ago
        bug? POSIX compliance? How?
        xcv123 3y ago
        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/V2_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...
pier25 3y ago
Amazing that Apple introduced a breaking change in a .4 release. Probably a mistake? Also amazing it wasn't caught during the beta period.
- mvdtnz 3y ago
  This kind of behaviour is very common from Apple.
- goosedragons 3y ago
  It wasn't in the public beta according to Oracle.
- empthought 3y ago
  Apple has never been a follower of semantic versioning.
  - lloeki 3y ago
    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
tiffanyh 3y ago
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).
- mdhb 3y ago
  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.
javajosh 3y ago
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.
- flohofwoe 3y ago
  > it seems highly unlikely that the macos people don't test anything on the jvm during acceptance. I would be surprised if they do to be honest (Apple doesn't even catch obvious bugs in the new macOS settings panel, which really makes me wonder if there is a software QA process at all). For 3rd party apps they seem to rely on the software vendors to holler if a macOS update breaks their app. That's why the macOS prerelease versions exist. But since the bug wasn't present in the prerelease, affected vendors couldn't catch it. It's still a fuckup in Apple release process of course (which tbh also isn't surprising).
  - wyclif 3y ago
    What is the bug in the new System Settings panel?
    - overstay8930 3y ago
      No idea what OP if referring to but I could pretty consistently cause Settings to soft lock for a few months by loading a configuration profile while the settings window was open, just small things like that are basically everywhere in macOS. Don't even get me started on Screen Time bugs...
    - flohofwoe 3y ago
      I'm stumbling over a couple of annoying problems when opening the DNS server subpanel via search (because without search it's pretty much impossible to find that panel, but that's a separate issue). One is that occasionally there's an error popup "Extension process Network(4433) exited." just when clicking on the 'DNS servers' search result. The other is that when accidentally hitting "Enter" after entering a new DNS server address the entire DNS Server subpanel will close even though I want to enter a second address (which sucks from a user perspective, but might even be consistent with the UX guidelines, but OTH I would expect pressing Enter on a text input box would not close the UI panel which contains the text input box, but maybe that's just me). But then clicking on the previous search result 'DNS servers' to open the DNS servers panel again, the click does nothing this time. One has to clear the search box, enter the search term again, perform a new search, and then click the search result 'DNS servers' again to get the subpanel for entering DNS server addresses. I guess the search is also broken like this for other subpanels, but changing the DNS servers is about the only situation where I'm using the search box. In the old settings panel all that worked as expected (and apart from that, everything also was a lot snappier, somehow Apple engineers managed to create simple Settings window that suffers from performance problems, but again, different issue).
w10-1 3y ago
"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.
- kaba0 3y ago
  > 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. As far as I understand, that’s not the issue, the JIT itself works just fine. The JVM just uses the (quite common) trick that it doesn’t actually bound check everything, but let’s the hardware trigger an interrupt, expecting that to “bubble up” to the program at hand, so it can handle certain cases “for free”. This behavior was changed by apple, which causes issues.
  - exabrial 3y ago
    Why not just let it bubble up from the hardware? Seems like a redundant thing to build into the kernel
- vips7L 3y ago
  This is honestly a wild and out there claim. The OpenJdk team would never want to see this happen to their user base. They’re some of the most professional programmers I’ve ever seen. The whole truth is that the Apple kernel team broke user space.
not_me_ever 3y ago
Wait, they write to protected memory, and get killed. :tripplefacepalm: Somebody hire some engineers at Oracle.
- kaba0 3y ago
  Sarcasm only works when you are actually smart and know what you are talking about.
- erik_seaberg 3y ago
  To finish validating a request and then start executing it creates a race condition. That's why execution always needed to fail in a recoverable way.
millzlane 3y ago
14.4 also killed automated device enrollment in VMware's workspaceone. We're having to downgrade brand new MacBooks to 14.3 using configurator.
sebazzz 3y ago
Isn't this just W^X?
Anamon 3y ago
Another example for how preventing users from doing rollbacks is a terrible practice. Even if it's not your application's fault, users may have very good reasons to revert an update, if only temporarily. This also bothers me on Android. Sometimes, an app update may break something and prevent me from using it. But Google doesn't allow me to reinstall a previously published version from the Play Store. If I don't have to (or can't easily) do without that application until a fix might be released, my only option is to find an older release on some shady mirror site.
tebruno99 2y ago
It is always funny to Me when Apple zealots come into threads blaming everyone but Apple that software broke. Complaining Java doesn’t follow Apple standards or some crap. Then 9 days later Apple issues a fix because they did indeed break it.
- w10-1 2y ago
  Yes, you mean: https://support.apple.com/en-us/109035 https://support.apple.com/en-us/109035 Can you tell from this or any other Oracle bug whether Apple is bending its rules for Java? I can't tell either way.
npalli 3y ago
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?
- bombcar 3y ago
  Minecraft runs on various Javas. And there's a known issue with an interaction between minecraft, Java, and the video drivers that crashes out and it can be traced back all the way to here: https://github.com/glfw/glfw/issues/1997 https://github.com/glfw/glfw/issues/1997 It's not fixed.
- nurettin 3y ago
  Sonoma has been out for only one week!
  - stalfosknight 3y ago
    Sonoma became generally available September 26, 2023.
    - grodriguez100 3y ago
      However 14.4 was released days ago (March 7).
      - stalfosknight 3y ago
        The .4 is not what makes it Sonoma. The 14 is.
        grodriguez100 3y ago
        Yes, I know.
- CharlesW 3y ago
CharlesW 3y ago
> "As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions." I'm just a lowly JavaScript/TypeScript/PHP programmer, but what is the Very Good Reason that Java trying to access other processes' memory?
- olliej 3y ago
  It depends on exactly what is being done. A fairly common idiom is to use memory protection to provide zero cost access checks, as you can generally catch the signals produced by most memory faults, and then work out where things went wrong and convert the memory access error into a catchable exception, or to lazily construct data structures or code. So you want the trap, but the trap itself can be handled. It sounds like there’s been a semantic change when the trap occurs for execution of an address or an access to an executable page. There are also a bunch of poorly documented Mac APIs to inform the memory manager and linker about JIT regions and I wonder if it’s related to those. It really depends on exactly what oracle’s jvm is trying to do, and what the subsequent cause of the fault is. Certainly it’s a less than optimal failure though :-/
- samus 3y ago
  Accessing such areas is sometimes done deliberately since programmers could rely on the OS telling them what just happened using signals instead of nuking the process wholesale. Doing it without signals is usually slow and/or clunky (null-pointer checks, read/write permissions, existence of pages), or straight out impossible. Accessing other processes' memory is not the concern since virtual memory provides each process the illusion of having the entire address space for itself.
- toast0 3y ago
  In a virtual memory operating system, every program has its own address space. Accessing an unmapped address is not the same as trying to access another process's memory. It's also pretty common to use memory protection to autoextend stacks... Allocate the stack size you need, ask the OS to mark the page(s) after the stack as protected, catch the signal when you hit the protection, allocate some more stack and a new protected page unless the stack is too big. Works for heaps too. Let the MMU hardware check accesses, so you don't have to check everything in software all the time.
MaxBarraclough 3y ago
Is the signals change in macOS likely to affect JIT-based systems other than the OpenJDK JVM?
xyst 3y ago
Apple 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.
- open592 3y ago
  Here’s the YouTube link from Mitchell. I was thinking about doing something similar lately too. https://youtu.be/ubDMLoWz76U?si=ipmho73-r9FzZpBp https://youtu.be/ubDMLoWz76U?si=ipmho73-r9FzZpBp
- nullwarp 3y ago
  This is what I do when my job forced me to use a mac. I think the only thing I installed on the mac outside of it was Firefox. Worked great for years before I changed jobs that let me bring my own hardware finally.
  - neeleshs 3y ago
    What is your preferred hardware and flavor of Linux for this? I'm trying to do the same
    - rzzzt 3y ago
      Rancher Desktop used Lima + QEMU behind the scenes: https://lima-vm.io/ https://lima-vm.io/
    - mktk1001 3y ago
      Tbh no one matches the hardware quality of MacBooks. But I refuse to use them on principle. Thinkpad t14 been serving me well (using fedora).
- Kipters 3y ago
  To be fair, this is the kind of breakage I'd expect from macOS, but never from Windows
- secondcoming 3y ago

235 points by kingds 3y ago

sunshinerag 3y ago

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

metanonsense 3y ago
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.

DuskHorizon 3y ago

Well, that’s why Apple forbids use of private APIs in the App Store apps. If you built all your tech stack on the foundation of some peculiar nondocumented platform’s behavior, don’t be surprised when this stack breaks.

bhawks 3y ago
This is not an API. It's the handling of writes to memory the process has protected. In the past this would generate a signal the process could handle and recover from. Now it generates a sigkill which is uncatchable / unrecoverable from. These behaviours have been historically well documented.
- DuskHorizon 3y ago
  All system idiosyncrasies are APIs in the long run ;)
  - fifteen1506 3y ago
    The change of a SIGSEGV to a SIGKILL, seriously?
    - DuskHorizon 3y ago
      And, why not? macOS is Apple’s IP and they have all rights to do with it as they want. Buy the way, Chrome/Node.js JavaScript engine uses JIT compilation too. Are they affected?
      - samus 3y ago
        This breaks POSIX compatibility, which is basically saying FU to how a lot of developers expect to interact with an operating system for decades now.
        jandrewrogers 3y ago
        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.
        xcv123 3y ago
        POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...
        kmiller68 3y ago
        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.

olliej 3y ago

A gross and low performance option for now might be to run Java under Rosetta, but I’m saying that based on them saying that this is apple silicon specifically and processes under rosetta have a bunch of quirks to support intel semantics. This would allow you to work around this for now. That said I’m curious what the exact scenario that leads to this is, I’m assuming it’s not common as you would expect it to have come up during betas and pre -release seeds.

grodriguez100 3y ago
> I’m assuming it’s not common as you would expect it to have come up during betas and pre -release seeds. The article specifically says that the issue was not present in early access releases, so it was not possible to discover it before the actual release.

fwlr 3y ago

“The Java Virtual Machine […] leverages the protected memory access signal mechanism both for correctness (e.g., to handle the truncation of memory mapped files) and for performance.” Where by “protected memory access signal mechanism”, they mean SIGBUS/SIGSEGV, i.e., a segfault. This is probably because the JVM is doing “zero cost access checks”, which is where you do the moral equivalent of: try { writeToFile() } catch(err) { if (err == SYSTEM_CRASH_IMMINENT) { changeFilePermissions() retry } } …because it’s faster than checking file permissions before every write. (It’s a common pattern in systems programming, so it’s not quite as crazy as it sounds.) I guess my opinion on this is that if you write your program to intentionally trigger and ignore kill(10) / kill(11) from the host OS, for the sake of a speed boost, you can’t really get too mad when the host OS gets fed up and starts sending kill(9) instead. I also wonder what happens in the (extremely rare) case where the signal the JVM is trapping is a real segfault, and not an operating system signal.

dzaima 3y ago
This isn't about files, this is about plain pages of RAM[0]. It is a basic CPU operation to trap on unmapped pages, and OSes rightfully expose this useful feature (in addition to using it themselves), allowing processes to do many things, from lazily-computed memory regions to removing significant amounts of overhead doing a thing the CPU will inevitably do itself anyway. I believe the "the truncation of memory mapped files" section is for when the Java process memory-maps a file (as Java provides memory-mapping operations in its standard library, and probably also uses them itself), and afterwards some other unrelated process truncates the file, resulting in the OS quietly making (parts of) the mappings inaccessible. Here the process couldn't even check the permissions before reading (never mind how utterly hilariously inefficient that would be, defeating the purpose of memory-mapping) as the mappings could change between the check and subsequent read anyway. [0]: https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860, "I've managed to narrow this down to this small reproducer:" section
- fwlr 3y ago
  You are of course completely correct. However, I still stand by my pseudocode - I claim that it will give a fairly accurate impression of the basic concept of zero-cost access checks to a reader who isn’t familiar with low-level systems programming. (That said, I have updated my comment to make it clear it’s more of a metaphor than a literal description.)

riscy 3y ago

> 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, it’s the JIT thread privileged to write to executable pages that is performing illegal memory accesses. That’s typically a sign of a bug, and allowing a thread with write access to executable pages to continue executing after that is a security risk. But I know of other language runtimes that take advantage of installing signal handlers for SIGBUS/SIGSEGV to detect when they overflow a page so they can allocate more memory, etc. This saves from having to do an explicit overflow check on every allocation. Those threads aren’t given privilege to write to executable memory, so they’re not seeing this issue… So this sounds like a narrow design problem the JVM is facing with their JIT thread. This blog doesn’t explain why their JIT thread needs to make illegal memory accesses instead of an explicit check.

LadyCailin 3y ago
It said it affected back to Java 8, so seems like this design has been there for a while, and since older versions are EOL, any Java level fix would not be patched back.
- flohofwoe 3y ago
  I wonder what that means for the Android SDK, which AFAIK requires an ancient Java8 runtime for the command line SDK tools on macOS.
  - saurik 3y ago
    They now seem to work with Java 11.
  - vbezhenar 3y ago
    Java 8 is not EOL.

ivan_gammel 3y ago

I wonder if it's the same reason as why Civilization 6 stopped working on iPadOS 17.4. Did they change something deep in the kernel for DMA compliance?

INGSOCIALITE 3y ago

[flagged]

zx8080 3y ago

The main question now is why hasn't it been exposed in pre-release 14.4. This could mean some very urgent and risky change got its way to the 14.4 release, or that the whole macos release process is broken and unstable.

8crazyideas 3y ago

I just bought a MacBook Pro with the M3 Max chip and installed MATLAB R2023b. Sonoma 14.3 is in place. As a requirement, I had to also install Corretto 8. MathWorks only supports the Java 8 JRE included with Amazon Corretto 8. I am already having several problems in MATLAB with his new setup. Can I assume that updating to Sonoma 14.4 might very well cause even more problems? I really don't understand any of this.

xcv123 3y ago
".. 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.
- ls612 3y ago
  Is it Apple or Oracle who should rightly be fixing this issue?
  - xcv123 3y ago
    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.
    - sunshinerag 3y ago
      bug? POSIX compliance? How?
      - xcv123 3y ago
        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/V2_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

pier25 3y ago

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

mvdtnz 3y ago
This kind of behaviour is very common from Apple.
goosedragons 3y ago
It wasn't in the public beta according to Oracle.
empthought 3y ago
Apple has never been a follower of semantic versioning.
- lloeki 3y ago
  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

tiffanyh 3y ago

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

mdhb 3y ago
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.

javajosh 3y ago

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.

flohofwoe 3y ago
> it seems highly unlikely that the macos people don't test anything on the jvm during acceptance. I would be surprised if they do to be honest (Apple doesn't even catch obvious bugs in the new macOS settings panel, which really makes me wonder if there is a software QA process at all). For 3rd party apps they seem to rely on the software vendors to holler if a macOS update breaks their app. That's why the macOS prerelease versions exist. But since the bug wasn't present in the prerelease, affected vendors couldn't catch it. It's still a fuckup in Apple release process of course (which tbh also isn't surprising).
- wyclif 3y ago
  What is the bug in the new System Settings panel?
  - overstay8930 3y ago
    No idea what OP if referring to but I could pretty consistently cause Settings to soft lock for a few months by loading a configuration profile while the settings window was open, just small things like that are basically everywhere in macOS. Don't even get me started on Screen Time bugs...
  - flohofwoe 3y ago
    I'm stumbling over a couple of annoying problems when opening the DNS server subpanel via search (because without search it's pretty much impossible to find that panel, but that's a separate issue). One is that occasionally there's an error popup "Extension process Network(4433) exited." just when clicking on the 'DNS servers' search result. The other is that when accidentally hitting "Enter" after entering a new DNS server address the entire DNS Server subpanel will close even though I want to enter a second address (which sucks from a user perspective, but might even be consistent with the UX guidelines, but OTH I would expect pressing Enter on a text input box would not close the UI panel which contains the text input box, but maybe that's just me). But then clicking on the previous search result 'DNS servers' to open the DNS servers panel again, the click does nothing this time. One has to clear the search box, enter the search term again, perform a new search, and then click the search result 'DNS servers' again to get the subpanel for entering DNS server addresses. I guess the search is also broken like this for other subpanels, but changing the DNS servers is about the only situation where I'm using the search box. In the old settings panel all that worked as expected (and apart from that, everything also was a lot snappier, somehow Apple engineers managed to create simple Settings window that suffers from performance problems, but again, different issue).

w10-1 3y ago

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

kaba0 3y ago
> 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. As far as I understand, that’s not the issue, the JIT itself works just fine. The JVM just uses the (quite common) trick that it doesn’t actually bound check everything, but let’s the hardware trigger an interrupt, expecting that to “bubble up” to the program at hand, so it can handle certain cases “for free”. This behavior was changed by apple, which causes issues.
- exabrial 3y ago
  Why not just let it bubble up from the hardware? Seems like a redundant thing to build into the kernel
vips7L 3y ago
This is honestly a wild and out there claim. The OpenJdk team would never want to see this happen to their user base. They’re some of the most professional programmers I’ve ever seen. The whole truth is that the Apple kernel team broke user space.

not_me_ever 3y ago

Wait, they write to protected memory, and get killed. :tripplefacepalm: Somebody hire some engineers at Oracle.

kaba0 3y ago
Sarcasm only works when you are actually smart and know what you are talking about.
erik_seaberg 3y ago
To finish validating a request and then start executing it creates a race condition. That's why execution always needed to fail in a recoverable way.

millzlane 3y ago

14.4 also killed automated device enrollment in VMware's workspaceone. We're having to downgrade brand new MacBooks to 14.3 using configurator.

sebazzz 3y ago

Isn't this just W^X?

Anamon 3y ago

Another example for how preventing users from doing rollbacks is a terrible practice. Even if it's not your application's fault, users may have very good reasons to revert an update, if only temporarily. This also bothers me on Android. Sometimes, an app update may break something and prevent me from using it. But Google doesn't allow me to reinstall a previously published version from the Play Store. If I don't have to (or can't easily) do without that application until a fix might be released, my only option is to find an older release on some shady mirror site.

tebruno99 2y ago

It is always funny to Me when Apple zealots come into threads blaming everyone but Apple that software broke. Complaining Java doesn’t follow Apple standards or some crap. Then 9 days later Apple issues a fix because they did indeed break it.

w10-1 2y ago
Yes, you mean: https://support.apple.com/en-us/109035 https://support.apple.com/en-us/109035 Can you tell from this or any other Oracle bug whether Apple is bending its rules for Java? I can't tell either way.

npalli 3y ago

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?

bombcar 3y ago
Minecraft runs on various Javas. And there's a known issue with an interaction between minecraft, Java, and the video drivers that crashes out and it can be traced back all the way to here: https://github.com/glfw/glfw/issues/1997 https://github.com/glfw/glfw/issues/1997 It's not fixed.
nurettin 3y ago
Sonoma has been out for only one week!
- stalfosknight 3y ago
  Sonoma became generally available September 26, 2023.
  - grodriguez100 3y ago
    However 14.4 was released days ago (March 7).
    - stalfosknight 3y ago
      The .4 is not what makes it Sonoma. The 14 is.
      - grodriguez100 3y ago
        Yes, I know.
CharlesW 3y ago

CharlesW 3y ago

> "As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions." I'm just a lowly JavaScript/TypeScript/PHP programmer, but what is the Very Good Reason that Java trying to access other processes' memory?

olliej 3y ago
It depends on exactly what is being done. A fairly common idiom is to use memory protection to provide zero cost access checks, as you can generally catch the signals produced by most memory faults, and then work out where things went wrong and convert the memory access error into a catchable exception, or to lazily construct data structures or code. So you want the trap, but the trap itself can be handled. It sounds like there’s been a semantic change when the trap occurs for execution of an address or an access to an executable page. There are also a bunch of poorly documented Mac APIs to inform the memory manager and linker about JIT regions and I wonder if it’s related to those. It really depends on exactly what oracle’s jvm is trying to do, and what the subsequent cause of the fault is. Certainly it’s a less than optimal failure though :-/
samus 3y ago
Accessing such areas is sometimes done deliberately since programmers could rely on the OS telling them what just happened using signals instead of nuking the process wholesale. Doing it without signals is usually slow and/or clunky (null-pointer checks, read/write permissions, existence of pages), or straight out impossible. Accessing other processes' memory is not the concern since virtual memory provides each process the illusion of having the entire address space for itself.
toast0 3y ago
In a virtual memory operating system, every program has its own address space. Accessing an unmapped address is not the same as trying to access another process's memory. It's also pretty common to use memory protection to autoextend stacks... Allocate the stack size you need, ask the OS to mark the page(s) after the stack as protected, catch the signal when you hit the protection, allocate some more stack and a new protected page unless the stack is too big. Works for heaps too. Let the MMU hardware check accesses, so you don't have to check everything in software all the time.

MaxBarraclough 3y ago

Is the signals change in macOS likely to affect JIT-based systems other than the OpenJDK JVM?

xyst 3y ago

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

open592 3y ago
Here’s the YouTube link from Mitchell. I was thinking about doing something similar lately too. https://youtu.be/ubDMLoWz76U?si=ipmho73-r9FzZpBp https://youtu.be/ubDMLoWz76U?si=ipmho73-r9FzZpBp
nullwarp 3y ago
This is what I do when my job forced me to use a mac. I think the only thing I installed on the mac outside of it was Firefox. Worked great for years before I changed jobs that let me bring my own hardware finally.
- neeleshs 3y ago
  What is your preferred hardware and flavor of Linux for this? I'm trying to do the same
  - rzzzt 3y ago
    Rancher Desktop used Lima + QEMU behind the scenes: https://lima-vm.io/ https://lima-vm.io/
  - mktk1001 3y ago
    Tbh no one matches the hardware quality of MacBooks. But I refuse to use them on principle. Thinkpad t14 been serving me well (using fedora).
Kipters 3y ago
To be fair, this is the kind of breakage I'd expect from macOS, but never from Windows
secondcoming 3y ago