JDK-8255466 : C2 crashes at ciObject::get_oop() const+0x0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,15.0.1,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-27
  • Updated: 2024-12-09
  • Resolved: 2020-10-29
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 16 JDK 8
11.0.10Fixed 16 b23Fixed 8u371Fixed
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f72907ab7d0, pid=5586, tid=5722
#
# JRE version: Java(TM) SE Runtime Environment GraalVM LIBGRAAL_EE 20.3.0-dev (15.0.1+7) (build 15.0.1+7-LTS-jvmci-20.3-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM GraalVM LIBGRAAL_EE 20.3.0-dev (15.0.1+7-LTS-jvmci-20.3-b02, mixed mode, tiered, jvmci, compressed oops, parallel gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4b57d0]  ciObject::get_oop() const+0x0

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

Current thread (0x00007f7138000d20):  JavaThread "C2 CompilerThread9" daemon [_thread_in_vm, id=5722, stack(0x00007f71840f7000,0x00007f71841f8000)]


Current CompileTask:
C2:   5950 6452       4       java.lang.Class::annotationData (44 bytes)

Stack: [0x00007f71840f7000,0x00007f71841f8000],  sp=0x00007f71841f2f58,  free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x4b57d0]  ciObject::get_oop() const+0x0
V  [libjvm.so+0xd1aab6]  TypeOopPtr::TypeOopPtr(Type::TYPES, TypePtr::PTR, ciKlass*, bool, ciObject*, int, int, TypePtr const*, int)+0x286
V  [libjvm.so+0xd1c9c2]  TypeInstPtr::add_offset(long) const+0x1b2
V  [libjvm.so+0xd1c843]  TypeInstPtr::add_offset(long) const+0x33
V  [libjvm.so+0xb9ab1c]  PhaseIterGVN::transform_old(Node*)+0x12c
V  [libjvm.so+0xb97819]  PhaseIterGVN::optimize()+0x109
V  [libjvm.so+0x517943]  Compile::inline_incrementally_cleanup(PhaseIterGVN&)+0x3e3
V  [libjvm.so+0x518105]  Compile::inline_incrementally(PhaseIterGVN&)+0x5a5
V  [libjvm.so+0x521180]  Compile::Optimize()+0x430
V  [libjvm.so+0x5233b2]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1102
V  [libjvm.so+0x46fb5c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xfc
V  [libjvm.so+0x52b818]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd18
V  [libjvm.so+0x52c318]  CompileBroker::compiler_thread_loop()+0x4c8
V  [libjvm.so+0xcf966e]  JavaThread::thread_main_inner()+0xde
V  [libjvm.so+0xcfe4dd]  Thread::call_run()+0xfd
V  [libjvm.so+0xb51677]  thread_native_entry(Thread*)+0xe7
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk8u-dev/pull/536 Date: 2024-07-07 08:55:07 +0000
09-07-2024
The patch also fix the compiler warning "hotspot/src/share/vm/opto/type.cpp:2556:71: error: ‘this’ pointer is null" with gcc13.
09-07-2024
working on backport to jdk8u
27-07-2023
Fix Request (11u) Fixes the corner case in C2, and keeps codebases in sync (I see 11.0.11-oracle). Patch does not apply cleanly due to different context. 11u RFR (acked by phh): https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-November/004140.html New test fails without the patch, passes with it. tier{1,2} also passes.
16-11-2020
Changeset: 56eb5f54 Author: Vladimir Kozlov <kvn@openjdk.org> Date: 2020-10-29 22:34:14 +0000 URL: https://git.openjdk.java.net/jdk/commit/56eb5f54
29-10-2020
Call stack: V [libjvm.so+0x1892bb3] TypeOopPtr::TypeOopPtr(Type::TYPES, TypePtr::PTR, ciKlass*, bool, ciObject*, int, int, TypePtr const*, int)+0x5d3 V [libjvm.so+0x189362d] TypeInstPtr::make(TypePtr::PTR, ciKlass*, bool, ciObject*, int, int, TypePtr const*, int) [clone .constprop.1]+0x14d V [libjvm.so+0x1893e88] TypeInstPtr::add_offset(long) const+0xc8 V [libjvm.so+0x15d52e7] PhaseGVN::transform_no_reclaim(Node*)+0x1a7 V [libjvm.so+0x125f839] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x4f9 V [libjvm.so+0x1282b41] LibraryIntrinsic::generate(JVMState*)+0x211 V [libjvm.so+0xb530b2] Parse::do_call()+0x502 Type: oopptr:NotNull:exact+128 java/lang/Class I verified that my changes fixed it.
29-10-2020
Thank you, Tom! I will create jtreg test from it.
29-10-2020
Actually this reproduces trivially for me when the offset is a static final constant but the base isn't. The attached unsafecl.java crashes with Xcomp in every release I tried. $ ~/mx-jdk/jdk-15.0.1.jdk/Contents/Home/bin/java -Xcomp unsafecl # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000108e6c534, pid=62977, tid=23555 # # JRE version: Java(TM) SE Runtime Environment (15.0.1+6) (build 15.0.1+6-14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (15.0.1+6-14, compiled mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # V [libjvm.dylib+0x26c534] ciObject::get_oop() const+0x4 # # 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: # /Users/tkrodrig/hs_err_pid62977.log # # Compiler replay data is saved as: # /Users/tkrodrig/replay_pid62977.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp #
29-10-2020
I've been trying to reproduce in hopes of getting replay but haven't had any luck yet. I did notice that one of the crashes by change captured a replay file but it's mostly unusable because it is full of lambdas and method handles. I have attached it in case any clues can be gleaned from it. I notice that there are ciMethods for DirectMethodHandle.staticBase and DirectMethodHandle.staticOffset which suggest that reflective static field operation is coming from some method handles logic. If so that also means a replay will be useless for reproducing it.
29-10-2020
ILW = Crash during C2 compilation, intermittent, no known workaround but disable compilation of affected method = HLM = P3
28-10-2020
We should do similar runtime check similar to other place in C2: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L1615
27-10-2020
[~never] pointed that it could be "reflective unsafe static field access that would eventually be optimized away because the Class is null." One suggestion is to convert the assertion at https://github.com/openjdk/jdk/blob/0c99b192588b04aceaa27cda9cb42b45f95adffe/src/hotspot/share/opto/type.cpp#L3049 into runtime check: // Static fields if (o != NULL) { ciInstanceKlass* k = o->as_instance()->java_lang_Class_klass()->as_instance_klass(); The attached hs_err shows C2 is crashing while compiling Class::annotationData which has a CAS of an instance field for java.lang.Class[1]. [1] https://github.com/openjdk/jdk/blob/0aa3c92577687e02f941260dc0f176f9dcd4ae59/src/java.base/share/classes/java/lang/Class.java#L3980
27-10-2020