JDK-8239387 : [Graal] crash in Klass::layout_helper()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 15
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-02-19
  • Updated: 2020-07-03
  • Resolved: 2020-07-02
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8248013 - Crash occurs in java/lang/StackWalker/LocalsAndOperands.java
Relates :  
JDK-8239569 - PublicMethodsTest.java failed due to NPE in java.base/java.nio.file.FileSystems.getFileSystem(FileSystems.java:230)
Relates :  
JDK-8248013 - Crash occurs in java/lang/StackWalker/LocalsAndOperands.java
Relates :  
JDK-8248432 - StackWalker/LocalsAndOperands.java crashes with -Xcomp in loom repo
Description
java/lang/StackWalker/LocalsAndOperands.java#id0 executed in Graal as JIT mode crashed on macos with

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x000000011235e954, pid=22499, tid=27395
#
# JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-02-18-2131059.ekaterina.pavlova.jdk.jdk)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-02-18-2131059.ekaterina.pavlova.jdk.jdk, compiled mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0xaf4954]  Klass::layout_helper() const+0x4




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

Current thread (0x00007f9822268800):  GCTaskThread "GC Thread#11" [stack: 0x0000700004a3a000,0x0000700004b3a000] [id=27395]

Stack: [0x0000700004a3a000,0x0000700004b3a000],  sp=0x0000700004b39980,  free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xaf4954]  Klass::layout_helper() const+0x4
V  [libjvm.dylib+0xaf473f]  oopDesc::size_given_klass(Klass*)+0x1f
V  [libjvm.dylib+0x457390]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oop, markWord)+0xbc
V  [libjvm.dylib+0x4546f9]  void G1ParScanThreadState::do_oop_evac<unsigned int>(unsigned int*)+0x1d1
V  [libjvm.dylib+0x456e4e]  G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x236
V  [libjvm.dylib+0x456bf0]  G1ParScanThreadState::trim_queue()+0x1a
V  [libjvm.dylib+0x40118c]  G1ParEvacuateFollowersClosure::do_void()+0x38
V  [libjvm.dylib+0x4083a0]  G1EvacuateRegionsBaseTask::evacuate_live_objects(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases)+0x86
V  [libjvm.dylib+0x4081db]  G1EvacuateRegionsBaseTask::work(unsigned int)+0xaf
V  [libjvm.dylib+0xba3136]  GangWorker::run_task(WorkData)+0x60
V  [libjvm.dylib+0xba31df]  GangWorker::loop()+0x25
V  [libjvm.dylib+0xabb881]  Thread::call_run()+0x11b
V  [libjvm.dylib+0x93523c]  thread_native_entry(Thread*)+0xe0
C  [libsystem_pthread.dylib+0x3661]  _pthread_body+0x154
C  [libsystem_pthread.dylib+0x350d]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x2bf9]  thread_start+0xd


Flags use to run the test are:
 XX:+CreateCoredumpOnCrash -ea -esa -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:+TieredCompilation



Perhaps this is G1 related crash rather compiler one.
Comments
I can reproduce a problem with C2 oopmaps in jdk15-19, jdk15-20, but not after that. In jdk15-21 JDK-8239569 fixed a problem that could explain the April C2 crash.
03-07-2020
There was one crash with Graal and one with C2. The C2 crash was in applications/microbenchmarks/other/Test_14.java#id19, but I can't reproduce it, and it depends on nashorn which has been removed. The crash in StackWalker/LocalsAndOperands.java looks close enough to JDK-8248013 that I'm closing this as a duplicate.
02-07-2020
Ah, right. Missed that.
26-06-2020
[~thartmann] It was excluded for -Xcomp -XX:-TieredCompilation, but still gets run with -Xcomp.
25-06-2020
Similar crashes: JDK-8248013, JDK-8202356, JDK-8227560. Isn't that test supposed to be excluded with Graal as JIT? http://hg.openjdk.java.net/jdk/hs/rev/1873626a5d67
24-06-2020
Looking at the latest core dump, the bad oop is 8 bytes past the beginning of an oop, and this bad oop is coming from the slot for rbp. Looking at the code, rpb is oop+8 along the path to the safepoint, so it should be marked as a derived oop in the oopmap, but I can't find a derived oop in the oopmap. The safepoint is call to _new_instance_Java because the TLAB allocation failed. It looks like rpb is bumped +8 after checking that the array[0] and array[1] are non-null. It is +8 for 2 narrow oops. Then later rbp is bumped +0x10 to add the oop header size, making rbp now point to the address of array[2]. It seems strange that c2 creates a derived oop that points into the oop header. I wonder if that is confusing things somewhere.
23-05-2020
The mdash query shows that a different test crashed at the same location on 4/16/20, without Graal: https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-15+19-827-tier8-20200416-1840-10239352/results?search=reasons.details%3A*layout_helper* So this might not be because of Graal. Both crashes were on MacOS.
15-05-2020