JDK-8235762 : JVM crash in SWPointer during C2 compilation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-12-11
  • Updated: 2020-06-01
  • Resolved: 2020-01-16
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 14 JDK 15
11.0.8-oracleFixed 14 b33Fixed 15Fixed
Related Reports
Duplicate :  
Relates :  
Description
Always reproducible on aarch64 linux platform with jdk14 slowdebug build.  

Reduced fuzz testcase :

public class Test {

    public static final int N = 400;
    public static byte bArr[] = new byte[N];
    public static int  iArr[] = new int[N];
    public static long lArr[] = new long[N];

    public static void vMeth(byte bArg, int iArg, long lArg) {
        int i = N - 1;
        do {
            iArr[i - 1] += iArg;
            iArr[i] += iArg;
            lArr[i - 1] = lArg;
            bArr[i - 1] = bArg;
        } while (--i > 0);
    }

    public void mainTest() {
        byte b = 0;
        int  i = 0;
        long l = 0;
        for (int j = 0; j < N; ++j) {
            vMeth(b, i, l);
        }
    }

    public static void main(String[] args) {
            Test _instance = new Test();
            for (int i = 0; i < 10; i++) {
                _instance.mainTest();
            }
    }

}

Command line: java -XX:CompileCommand=compileonly,Test::vMeth -XX:-TieredCompilation -XX:-BackgroundCompilation -XX:-UseOnStackReplacement Test

CompileCommand: compileonly Test.vMeth
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffffa90bb9ec, pid=11975, tid=11986
#
# JRE version: OpenJDK Runtime Environment (14.0) (slowdebug build 14-internal+0-adhoc.yangfei.openjdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 14-internal+0-adhoc.yangfei.openjdk-jdk, mixed mode, sharing, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x3149ec]  Node::in(unsigned int) const+0x14
#
# No core dump will be written. 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/114/hs_err_pid11975.log
#
# Compiler replay data is saved as:
# /home/yangfei/114/replay_pid11975.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 11986
Dumping core ...
Aborted

Call trace:

  24 ---------------  T H R E A D  ---------------
  25
  26 Current thread (0x000000003c24d000):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=11986, stack(0x0000ffff4e8dc000,0x0000ffff4eadd000)]
  27
  28
  29 Current CompileTask:
  30 C2:    573    1    b        Test::vMeth (54 bytes)
  31
  32 Stack: [0x0000ffff4e8dc000,0x0000ffff4eadd000],  sp=0x0000ffff4ead66d0,  free space=2025k
  33 Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
  34 V  [libjvm.so+0x3149ec]  Node::in(unsigned int) const+0x14
  35 V  [libjvm.so+0x1049cb4]  SWPointer::SWPointer(MemNode*, SuperWord*, Node_Stack*, bool)+0xb0
  36 V  [libjvm.so+0x1048ea0]  SuperWord::align_initial_loop_index(MemNode*)+0x228
  37 V  [libjvm.so+0x1043f3c]  SuperWord::output()+0xf4
  38 V  [libjvm.so+0x103c514]  SuperWord::SLP_extract()+0x4f4
  39 V  [libjvm.so+0x103b2c8]  SuperWord::transform_loop(IdealLoopTree*, bool)+0x4f8
  40 V  [libjvm.so+0xcb8a7c]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1268
  41 V  [libjvm.so+0x6a23d4]  PhaseIdealLoop::PhaseIdealLoop(PhaseIterGVN&, LoopOptsMode)+0x94
  42 V  [libjvm.so+0x6a2494]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x2c
  43 V  [libjvm.so+0x695840]  Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0xb8
  44 V  [libjvm.so+0x69656c]  Compile::Optimize()+0xb74
  45 V  [libjvm.so+0x68fab4]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xd4c
  46 V  [libjvm.so+0x58deb8]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x134
  47 V  [libjvm.so+0x6abf10]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x668
  48 V  [libjvm.so+0x6aacdc]  CompileBroker::compiler_thread_loop()+0x364
  49 V  [libjvm.so+0x10abd8c]  compiler_thread_entry(JavaThread*, Thread*)+0x80
  50 V  [libjvm.so+0x10a7168]  JavaThread::thread_main_inner()+0x170
  51 V  [libjvm.so+0x10a6fec]  JavaThread::run()+0x130
  52 V  [libjvm.so+0x10a2ea8]  Thread::call_run()+0x1a8
  53 V  [libjvm.so+0xe158b4]  thread_native_entry(Thread*)+0x1dc
  54 C  [libpthread.so.0+0x6dc4]  start_thread+0xa4


Comments
8u backport: AFAICT, this was introduced by JDK-8141624 which is not in 8u. The test case doesn't fail (on aarch64) with 8u. I don't think it needs to be backported as long as JDK-8141624 is not.
07-04-2020

11u Fix Request Backporting this patch eliminates a C2 crash. Patch does not apply cleanly to 11u and requires adjustments. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002920.html
27-03-2020

[~thartmann] & [~rraghavan] Thanks for reminding this and fixing it.
17-01-2020

Thank you [~thartmann]
16-01-2020

[~rraghavan] the fix was pushed to the wrong repo. I've backported it now to JDK 14.
16-01-2020

URL: https://hg.openjdk.java.net/jdk/jdk14/rev/d19d1a02d1b2 User: thartmann Date: 2020-01-16 07:03:30 +0000
16-01-2020

Hi [~fyang], [~thartmann], Any issue with JDK-8235762 fix commit? Understood from mailing list that the webrev review is done and got approval for push. But 8235762 here with fix version 14 is still open and there is 'HG Updates' message that related backport 8237258 is resolved fixed (JDK 15) May be the 8235762 fix push to jdk/jdk14 is missing !?
16-01-2020

Thanks Christian for confirming that. For the three notes: You should change int into uint here since orig_msize is of type uint: 718 for (int i = 0; i < orig_msize; i++) { -- OK, will modify accordingly when I am preparing webrev. And you can merge those two lines: 721 best_align_to_mem_ref = find_align_to_ref(memops, max_idx); 722 assert(best_align_to_mem_ref == NULL, "sanity"); together into: assert(find_align_to_ref(memops, max_idx) == NULL, "sanity"); since line 721 is part of the sanity check. Or just surround it by a #ifdef ASSERT. -- The purpose of line 721 here is to calculate the max_idx. So I don't think it's suitable to treat this line as assertion logic. Is max_idx always guaranteed to be valid and not -1? -- Yes, I think so. When memops is not empty and the memory ops in memops are not comparable, find_align_to_ref will always sets its max_idx.
11-12-2019

The test case in JDK-8235700 seems to work with your fix in the latest JDK 14 slowdebug build. While looking at your patch, some notes: You should change int into uint here since orig_msize is of type uint: 718 for (int i = 0; i < orig_msize; i++) { And you can merge those two lines: 721 best_align_to_mem_ref = find_align_to_ref(memops, max_idx); 722 assert(best_align_to_mem_ref == NULL, "sanity"); together into: assert(find_align_to_ref(memops, max_idx) == NULL, "sanity"); since line 721 is part of the sanity check. Or just surround it by a #ifdef ASSERT. Is max_idx always guaranteed to be valid and not -1?
11-12-2019

Okay, thanks. [~chagedorn], could you please check?
11-12-2019

@Tobias I tried to run the attached testcase on JDK-8235700 with the a jdk14 x86_64 release build, the crash is not triggered with -XX:UseAVX=1. The jdk14 used is built from the today's http://hg.openjdk.java.net/jdk/jdk repo and without my patch. So I cannot confirm whether my patch solves the problem on JDK-8235700 or not. Please help confirm if possible.
11-12-2019

No problem. Could you please verify that JDK-8235700 is the same issue (i.e. your fix solves the crash with the attached test - it requires UseAVX=1) and if so, close that issue as duplicate. Thanks.
11-12-2019

Sorry, I didn't noticed JDK-8235700 when I started to fix this bug several days ago. @Tobias
11-12-2019

ILW = Same as JDK-8235700 = P3
11-12-2019

Isn't this a duplicate of JDK-8235700?
11-12-2019

attached please find the proposed fix. (fix-superword.patch)
11-12-2019