JDK-8229496 : SIGFPE (division by zero) in C2 OSR compiled method
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-08-13
  • Updated: 2023-01-12
  • Resolved: 2019-09-05
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 11 JDK 13 JDK 14
11.0.6-oracleFixed 13.0.3Fixed 14 b14Fixed
Related Reports
Duplicate :  
JDK-8230186 - C2: SIGFPE in generated code
Duplicate :  
JDK-8288190 - crash with Problematic frame: # J 14% C2 Test.vMeth()V (181 bytes) @ 0x00007f68ad5866ea [0x00007f68ad5864c0+0x22a]
Relates :  
JDK-8230671 - x86_32 build failures after JDK-8229496
Relates :  
JDK-8234906 - [TESTBUG] TestDivZeroCheckControl fails for client VMs due to Unrecognized VM option LoopUnrollLimit
Relates :  
JDK-8256003 - TestDivZeroCheckControl.java times out
Relates :  
JDK-8242108 - Performance regression after fix for JDK-8229496
Relates :  
JDK-8257822 - C2 crashes with SIGFPE due to a division that floats above its zero check
Relates :  
JDK-8233656 - assert(d->is_CFG() && n->is_CFG()) failed: must have CFG nodes
Description
(provisional synopsis, please change as you see fit)

Found by fuzzing. Test crashes almost certainly. The bundle is attached. It has a few hs_errs inside.

$ ~/trunks/jdk-jdk/build/linux-x86_64-server-fastdebug/images/jdk/bin/java Test

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007fa13c318886, pid=18763, tid=18764
#
# JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.shade.jdk-jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# J 58% c2 Test.vMeth(II)V (362 bytes) @ 0x00007fa13c318886 [0x00007fa13c3186c0+0x00000000000001c6]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/shade/trunks/JavaFuzzer/tests/04170/core.18763)
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: Test

Host: shade-desktop, Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz, 16 cores, 125G, Ubuntu 18.04.3 LTS
Time: Tue Aug 13 21:29:54 2019 CEST elapsed time: 0 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x00007fa14c023800):  JavaThread "main" [_thread_in_Java, id=18764, stack(0x00007fa1560b3000,0x00007fa1561b4000)]

Stack: [0x00007fa1560b3000,0x00007fa1561b4000],  sp=0x00007fa1561b2660,  free space=1021k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 58% c2 Test.vMeth(II)V (362 bytes) @ 0x00007fa13c318886 [0x00007fa13c3186c0+0x00000000000001c6]

Disassembly near SIGFPE shows this:

 33 d2                            xor    edx,edx
 83 fb ff                         cmp    ebx,0xffffffff
 74 03                            je     0x00000032
 99                               cdq    
 f7 fb                            idiv   ebx    ; <--- SIGFPE here (division by zero)
 89 14 24                         mov    DWORD PTR [rsp],edx
 eb 46                            jmp    0x0000007d

And register maps says divisor is indeed zero:
  RBX=0x0 is NULL
Comments
Fei Yang's comment is https://bugs.openjdk.org/browse/JDK-8248552
09-11-2022
I verified that JDK-8288190 is the same issue.
03-11-2022
Hi [~roland], I was wondering if this is the same as new bug https://bugs.openjdk.org/browse/JDK-8288190 (for 8) I tried your 8 patch as part of triage but receive errors on run: /linux-x64/jdk/lib/amd64/server/libjvm.so: undefined symbol: _ZN10CastLLNode5IdealEP8PhaseGVNb How can I make your patch run? Best, Daniel Edit. It seems this fix was backed out? Maybe I should try https://bugs.openjdk.org/browse/JDK-8241900 if anything (not yet ported either) Edit. JDK-8241900 does appear promising for fixing JDK-8288190. But it does not fix this issue (8229496)
02-11-2022
Fix Request for 13u Backporting this patch fixes the c2 crash. Applies cleanly to 13u, new test passes.
24-03-2020
Checked regression test compiler/loopopts/TestDivZeroCheckControl.java passes in jdk14 atr and latest CI.
30-01-2020
For 8u backport test purpose, please check if this reduced test case helps. public class Test { public static void vMeth() { int i11 = 1, i12, iArr1[] = new int[52]; init(iArr1); for (i12 = 51; 1 < i12; i12 -= 3) { try { i11 = -3 % i12; iArr1[i12] = 0 / iArr1[i12]; } catch (ArithmeticException a_e) {} } iArr1[i11] = 0; } public static void init(int[] iArr1) { for (int j = 0; j < iArr1.length; j++) { iArr1[j] =1; } } public static void main(String[] strArr) { for (int i = 0; i < 50000; i++) { vMeth(); } } } On x64 linux platform, execute: $java -XX:-TieredCompilation Test Crash log: # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007f36c9173976, pid=6666, tid=0x00007f36d4759700 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-debug-yangfei_2019_09_17_11_00-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux-amd64 compressed oops) # Problematic frame: # J 2 C2 Test.vMeth()V (47 bytes) @ 0x00007f36c9173976 [0x00007f36c91737e0+0x196] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/yangfei/test/1719/hs_err_pid6666.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 139873469437696 Dumping core ... Aborted (core dumped)
12-10-2019
I tried backporting this one to 8u. The patch doesn't apply cleanly: some code was moved to new files in the meantime, there's at least one change that this depends on that was not backported. Attached is a backported patch that compiles but I haven't done much testing with it. The crash doesn't reproduce with the test cases because they need a feature that's only available in newest releases (profile predicates). I couldn't think of a way to trigger the issue without it. So why it's clear the underlying problem exist in 8u (missing dependency), I can't tell if it can cause a failure or not. Given complexity of the backport and lack of test case, I'm not moving forward with the backport at this point.
08-10-2019
11u Fix Request Backporting this patch fixes a c2 crash. Patch applies cleanly to 11u. New test fails without the product patch, and passes with it. tier1 tests pass with the patch.
02-10-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/86b95fc6ca32 User: thartmann Date: 2019-09-05 11:56:29 +0000
05-09-2019
http://cr.openjdk.java.net/~thartmann/8229496/webrev.00/
28-08-2019
Summary: A DivI/ModINode loses direct control dependency to its div != 0 check (but remains being dominated by it) and is then moved to before that check by PhaseIdealLoop::dominated_by() because depends_only_on_test() is true. Gory details: - The inner do-while loop is unswitched based on the div != 0 check added by GraphKit::zero_check_int() when parsing the irem/idiv bytecode. - The div == 0 loop is always throwing an arithmetic exception (loop is removed), the div != 0 loop computes 1 % div where the ModI is not directly control dependent on the div != 0 check anymore (but on the preceeding array store check). - Loop predicates are added to the outer loop in PhaseIdealLoop::loop_predication_impl_helper() and since the ModI is control dependent on the array store range check once that one is converted to a predicate, PhaseIdealLoop::dominated_by() moves the ModI up as well because depends_only_on_test() is true: http://hg.openjdk.java.net/jdk/jdk/file/cb836bd08d58/src/hotspot/share/opto/loopopts.cpp#l272 - As a result, ModI is moved to before the outer loop while the div != 0 check from unswitching is before the inner loop(s).
27-08-2019
Attached simplified Test.java that reproduces the crash with: java -XX:LoopUnrollLimit=0 -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::test -XX:-TieredCompilation Test
20-08-2019