JDK-8276231 : ciReplay: SIGSEGV when replay compiling lambdas
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-11-01
  • Updated: 2021-12-13
  • Resolved: 2021-11-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 18
18 b24Fixed
Related Reports
Relates :  
Relates :  
Description
Given the following Test.java:

public class Test {
    public static void main(String[] args) {
    }
}

Results in a SIGSEGV when replay compiling:
$ java -Xcomp -XX:CompileCommand=compileonly,com.sun.tools.javac.parser.JavacParser\$\$Lambda*::* -XX:CompileCommand=option,com.sun.tools.javac.parser.JavacParser\$\$Lambda*::*,bool,DumpReplay,true Test.java
# Picking the first dumped replay file
$ java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid0x269fd_compid71.log

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f09dfba9a2c, pid=157857, tid=157858
#
# JRE version: Java(TM) SE Runtime Environment (18.0) (slowdebug build 18-internal+0-2021-11-01-1028080.christian...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 18-internal+0-2021-11-01-1028080.christian..., mixed mode, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x591a2c]  Array<unsigned short>::length() const+0xc
.........
Command Line: -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid0x269fd_compid71.log 
.........
Stack: [0x00007f3380f95000,0x00007f3381096000],  sp=0x00007f3381094470,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x591a2c]  Array<unsigned short>::length() const+0xc
V  [libjvm.so+0x7ec268]  Array<unsigned short>::index_of(unsigned short const&) const+0x1c
V  [libjvm.so+0x7ebea5]  Array<unsigned short>::find(unsigned short const&)+0x23
V  [libjvm.so+0x7e375c]  ConstantPool::cp_to_object_index(int)+0x34
V  [libjvm.so+0x7e5416]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, JavaThread*)+0xc2
V  [libjvm.so+0x5911c9]  ConstantPool::find_cached_constant_at(int, bool&, JavaThread*)+0x51
V  [libjvm.so+0x7199e2]  CompileReplay::parse_cp_ref(JavaThread*)+0x872
V  [libjvm.so+0x719d06]  CompileReplay::parse_klass(JavaThread*)+0x6a
V  [libjvm.so+0x71b300]  CompileReplay::process_instanceKlass(JavaThread*)+0x24
V  [libjvm.so+0x71a3c7]  CompileReplay::process_command(JavaThread*)+0x203
V  [libjvm.so+0x71a12b]  CompileReplay::process(JavaThread*)+0x5b
V  [libjvm.so+0x717012]  ciReplay::replay_impl(JavaThread*)+0xf2
V  [libjvm.so+0x716c80]  ciReplay::replay(JavaThread*)+0x18
V  [libjvm.so+0xb99932]  JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x2c9
V  [libjvm.so+0xb99a76]  JNI_CreateJavaVM+0x32
C  [libjli.so+0x7456]  InitializeJVM+0x13d
C  [libjli.so+0x4251]  JavaMain+0xdc
C  [libjli.so+0xad69]  ThreadJavaMain+0x27
Comments
Changeset: e5ffdf91 Author: Dean Long <dlong@openjdk.org> Date: 2021-11-16 17:25:38 +0000 URL: https://git.openjdk.java.net/jdk/commit/e5ffdf9120c14b38e4c8794888d2002e2686ebfc
16-11-2021

Linking the holder class first before trying to look up the constant pool object fixes the crash.
13-11-2021

ILW = crash in compiler replay = MMH = P3
01-11-2021