4 ms·

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 plat

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.
        xcv123 3y ago
        It's not random. It is occurring in response to protected memory access. Violates the spec.
        kmiller68 3y ago
        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.
      - xcv123 3y ago
        No. MacOS is UNIX Certified. This is a bug in MacOS. Breaks POSIX compliance.
        deleted 3y ago
        [deleted]
        DuskHorizon 3y ago
        macOS breaks POSIX compliance at many levels. It’s Unix only on paper, lol.
    - bitwize 3y ago
      It's Apple saying "What part of 'you cannot write to this page of memory don't you understand?"

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.
        xcv123 3y ago
        It's not random. It is occurring in response to protected memory access. Violates the spec.
        kmiller68 3y ago
        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.
    - xcv123 3y ago
      No. MacOS is UNIX Certified. This is a bug in MacOS. Breaks POSIX compliance.
      - deleted 3y ago
        [deleted]
      - DuskHorizon 3y ago
        macOS breaks POSIX compliance at many levels. It’s Unix only on paper, lol.
  - bitwize 3y ago
    It's Apple saying "What part of 'you cannot write to this page of memory don't you understand?"