|4 - Normal
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2015-04-22T20:43:09.000Z)
2015-04-30 Newton (Release Date: 2015-04-30)
It would appear that there exists software that takes a crowbar to the service door, busting through any facade of decency in order that it might thrust its unwashed hands into the clean room that is the specific implementation details of the signal delivery frame assembled by the kernel. In doing so, the software makes it rather difficult for
lx_sigreturn) to locate the original native signal delivery frame that we need to use when attempting to return from the signal handler.
We can attempt to maintain a parallel tracking structure in the call frames of the interposing signal handler. Ideally this will allow us to, when finding our delivery frame corrupted or relocated, locate the matching native context anyway. Critically this parallel structure should not be used for regular operation, but rather only in a last-ditch attempt to make pathologically broken software work at all. It will likely also break in spectacular fashion if the precise 1:1 mapping between signals delivered and
rt_sigreturn(2) calls made is not maintained.
OS-4214 lxbrand 64-bit signal delivery frame not quite right
OS-4215 lxbrand rt_sigreturn(2) could try to recover in the face of stack shenanigans
Reviewed by: Jerry Jelinek <firstname.lastname@example.org>
Reviewed by: Patrick Mooney <email@example.com>