3 ms·

POSIX.1-2017 specification. Section titled "Memory Protection" https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html https://pubs.opengroup

by 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
      When kernel developers violate POSIX standards and break the JVM (and other applications not yet reported), it's a bug. Can't justify it or make excuses. Apple really fucked up here. Linus Torvalds has a policy: "WE DO NOT BREAK USERSPACE!". You just don't release stupid changes like this in a kernel. I'm sure the team at Apple are not pleased that this bug got into production.
      - fifteen1506 3y ago
        Specially when changing that just on the last, final, release.
DuskHorizon 3y ago
2017? Wiki says macOS are UNIX 03 certified ;)
jandrewrogers 3y ago
Ah yes that is fairly clear, thanks, I was not able to find that. A plausible interpretation is that the kernel still reserves the right to terminate the process at anytime, including immediately after a general protection fault. Still an unexpected behavior, much like the Linux OOM killer.

by xcv123 3y ago

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
    When kernel developers violate POSIX standards and break the JVM (and other applications not yet reported), it's a bug. Can't justify it or make excuses. Apple really fucked up here. Linus Torvalds has a policy: "WE DO NOT BREAK USERSPACE!". You just don't release stupid changes like this in a kernel. I'm sure the team at Apple are not pleased that this bug got into production.
    - fifteen1506 3y ago
      Specially when changing that just on the last, final, release.

DuskHorizon 3y ago

2017? Wiki says macOS are UNIX 03 certified ;)

jandrewrogers 3y ago

Ah yes that is fairly clear, thanks, I was not able to find that. A plausible interpretation is that the kernel still reserves the right to terminate the process at anytime, including immediately after a general protection fault. Still an unexpected behavior, much like the Linux OOM killer.