RFR: 8286182: C2: crash with SIGFPE when executing compiled code

Tobias Hartmann thartmann at openjdk.java.net
Wed May 18 08:42:41 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.

I completely agree with Christian, we should **not** let the division float above its zero check for various reasons:
- The graph is in a broken/inconsistent state that might lead to all kinds of subsequent issues. For example, if the division floats upwards, the divisor can become statically known to be zero. The division could then be replaced by TOP which would propagate downwards while the zero check is not necessarily removed as well, leading to an unschedulable graph. The same can happen with overflows.
- Catching the SIGFPE has an impact on performance and can potentially happen in a hot path.
- There is a risk of ignoring a "real" SIGFPE caused by a C2 bug. For example, if C2 erroneously removes the zero check, we would just continue execution on a SIGFPE, making things worse by essentially converting a crash to a wrong execution issue that might lead to all kinds of weird failures that are hard to debug.

Given that this issue leads to massive failures in our fuzzer testing, I would suggest to back out [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) for now and properly re-implement it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8726


More information about the hotspot-compiler-dev mailing list