RFR: 8286182: C2: crash with SIGFPE when executing compiled code
Christian Hagedorn
chagedorn at openjdk.java.net
Tue May 17 17:44:49 UTC 2022
On Mon, 16 May 2022 12:36:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
> The bug is not assigned to me, but I have seen that the C2 code which checks for div by 0 is not aware of the new nodes from [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742).
> This fixes the VM to pass the reproducer. I'm not sure if more opcode checks are required to get added.
The fix looks reasonable to address the same problems in [JDK-8257822](https://bugs.openjdk.java.net/browse/JDK-8257822) and [JDK-8248552](https://bugs.openjdk.java.net/browse/JDK-8248552) for the new nodes `Div` and `Mod` nodes.
> The problem is that NoOvfDivI does not only depend on the zero-divisor check but a possible overflow check as well. So with this fix it is still possible for a SIGFPE to occur.
Do you have a failing test for this case? We've been seeing a lot of SIGFPE failures lately with Java Fuzzer. I have to walk through them to see if I can find a case that is still failing with this fix. Will get back with the result of this analysis.
> IIUC this trouble comes from the fact that on x86 a Div node must be pinned to its zero-divisor check but may float with regards to other control nodes. Maybe we can remove all this special handling and simply catch SIGFPE instead? The result is guaranteed to not be used in those cases so we may not worry about the correctness of the compiled code.
I'm not sure if we should rely on signal catching to fix the cases where a division is wrongly floating above its zero check. I think we should not intentionally leave a graph in a broken state with the intention to fix it later at runtime.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8726
More information about the hotspot-compiler-dev
mailing list