JDK-8351660 : C2: SIGFPE in unsigned_mod_value
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-03-11
  • Updated: 2025-04-24
  • Resolved: 2025-04-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b19Fixed
Related Reports
Causes :  
Description
I found this with the Template Framework JDK-8344942.

At the end of unsigned_mod_value, we compute:
return TypeClass::make(static_cast<Signed>(dividend % divisor));

But in this example, the "divisor" is zero, which leads to SIGFPE.

The SIGFPE happens both in debug and in product.

java -Xbatch -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x000077924282870f, pid=1597591, tid=1597605
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-internal-LTS-2025-03-11-0926490.emanuel...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-03-11-0926490.emanuel..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xc2870f]  UModLNode::Value(PhaseGVN*) const+0x1ff
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to .../build/linux-x64-debug/jdk/bin/core.1597591)
#
# An error report file with more information is saved as:
# ...n/hs_err_pid1597591.log
#
# Compiler replay data is saved as:
# ../replay_pid1597591.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)


Current CompileTask:
C2:2445   89   !b  4       Test::test (17 bytes)

Stack: [0x0000779220100000,0x0000779220200000],  sp=0x00007792201fb1f0,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc2870f]  UModLNode::Value(PhaseGVN*) const+0x1ff  (divnode.cpp:1326)
V  [libjvm.so+0x168390e]  PhaseIterGVN::transform_old(Node*)+0x36e  (phaseX.cpp:1236)
V  [libjvm.so+0x1679034]  PhaseIterGVN::optimize()+0x94  (phaseX.cpp:1046)
V  [libjvm.so+0xa807b3]  Compile::Optimize()+0x323  (compile.cpp:2294)
V  [libjvm.so+0xa8420f]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1ecf  (compile.cpp:858)
V  [libjvm.so+0x8c3d00]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x440  (c2compiler.cpp:141)
V  [libjvm.so+0xa91cec]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbfc  (compileBroker.cpp:2331)
V  [libjvm.so+0xa92c28]  CompileBroker::compiler_thread_loop()+0x598  (compileBroker.cpp:1975)
V  [libjvm.so+0xf7eb0f]  JavaThread::thread_main_inner()+0x12f  (javaThread.cpp:776)
V  [libjvm.so+0x1947b56]  Thread::call_run()+0xb6  (thread.cpp:231)
V  [libjvm.so+0x15fa1b8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:877)
C  [libc.so.6+0x9caa4]
Comments
Changeset: 04e2a062 Branch: master Author: Saranya Natarajan <saranya.natarajan@oracle.com> Committer: Damon Fenacci <dfenacci@openjdk.org> Date: 2025-04-10 07:59:09 +0000 URL: https://git.openjdk.org/jdk/commit/04e2a0621d80f23cf70b4649ec4c24dad28e8e2d
10-04-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24410 Date: 2025-04-03 10:29:08 +0000
03-04-2025

The fix for JDK-8345766 included emitting specific ModF/ModD nodes, which is optimized and converted to runtime calls after optimizations (not during parsing). In the scenario where there was usigned modulo operation, during optimization and conversion to runtime calls there was no check for division by zero.
03-04-2025

ILW = Crash during C2 compilation (regression in JDK 25), easy to reproduce but edge case, no workaround but disable compilation of affected method = HMM = P2
11-03-2025

Looks like this was introduced in JDK 25 b7, probably JDK-8345766, narrowing it down ... Update: Confirmed, it's a regression from JDK-8345766 in JDK 25 b07.
11-03-2025

I suspect it is a JDK25 regression of JDK-8332268, which introduced this code. Quick experiments show that it does not reproduce with JDK24.
11-03-2025