6 ms·
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
by 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 agoIt's not random. It is occurring in response to protected memory access. Violates the spec.
- kmiller68 3y agoIf 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 agoWhen 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 agoSpecially when changing that just on the last, final, release.