Hacker News new | ask | show | jobs
by kmiller68 823 days 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.
1 comments
xcv123 823 days ago
It's not random. It is occurring in response to protected memory access. Violates the spec.
link
kmiller68 823 days 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.
link
xcv123 823 days 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.

link
fifteen1506 821 days ago
Specially when changing that just on the last, final, release.
link