JDK-8224148 : Kitchensink crashes with assert(oopDesc::is_oop(obj)) failed with ZGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2019-05-17
  • Updated: 2021-06-07
  • Resolved: 2021-06-07
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 13
13Resolved
Related Reports
Relates :  
Description
Kitchensink crashed with today's jdk/jdk with ZGC in xml.transform benchmark thread in personal CI run; build contains only some G1-only changes.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/runtime/handles.cpp:36), pid=18454, tid=24138
#  assert(oopDesc::is_oop(obj)) failed: not an oop: 0x000010007c3cafb0
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-05-17-1113215.thomas.schatzl.hs)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-05-17-1113215.thomas.schatzl.hs, mixed mode, tiered, z gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd07bb0]  HandleArea::allocate_handle(oop)+0x160
#
# Core dump will be written. Default location: [...]/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.18454
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

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

Current thread (0x00007f7bc68a6270):  JavaThread "BenchmarkThread xml.transform 1" [_thread_in_vm, id=24138, stack(0x00007f7b31de0000,0x00007f7b31ee1000)]

Stack: [0x00007f7b31de0000,0x00007f7b31ee1000],  sp=0x00007f7b31eda640,  free space=1001k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd07bb0]  HandleArea::allocate_handle(oop)+0x160
V  [libjvm.so+0x1553ba4]  SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, Bytecodes::Code&, CallInfo&, Thread*)+0x424
V  [libjvm.so+0x1555f3d]  SharedRuntime::resolve_sub_helper(JavaThread*, bool, bool, Thread*)+0x18d
V  [libjvm.so+0x15564ce]  SharedRuntime::resolve_helper(JavaThread*, bool, bool, Thread*)+0x4e
V  [libjvm.so+0x1556a7f]  SharedRuntime::resolve_virtual_call_C(JavaThread*)+0xef
v  ~RuntimeStub::resolve_virtual_call
J 26457 c2 com.sun.org.apache.xml.internal.serializer.NamespaceMappings.pushNamespace(Ljava/lang/String;Ljava/lang/String;I)Z java.xml@13-internal (108 bytes) @ 0x00007f7df54e0e1c [0x00007f7df54e0100+0x0000000000000d1c]
J 26821 c2 com.sun.org.apache.xml.internal.serializer.ToStream.startPrefixMapping(Ljava/lang/String;Ljava/lang/String;Z)Z java.xml@13-internal (121 bytes) @ 0x00007f7df4a54440 [0x00007f7df4a543c0+0x0000000000000080]
J 27159 c2 com.sun.org.apache.xml.internal.serializer.ToXMLStream.namespaceAfterStartElement(Ljava/lang/String;Ljava/lang/String;)V java.xml@13-internal (51 bytes) @ 0x00007f7df56abe58 [0x00007f7df56abb60+0x00000000000002f8]
J 28842 c1 die.verwandlung.balance_sheet.template$dot$1(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;I)V jdk.translet (296 bytes) @ 0x00007f7dee5708d4 [0x00007f7dee5707c0+0x0000000000000114]
j  die.verwandlung.balance_sheet.applyTemplates(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;)V+232 jdk.translet
j  die.verwandlung.balance_sheet.template$dot$0(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;I)V+579 jdk.translet
j  die.verwandlung.balance_sheet.applyTemplates(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;)V+218 jdk.translet
j  die.verwandlung.balance_sheet.applyTemplates(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;)V+293 jdk.translet
j  die.verwandlung.balance_sheet.transform(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/dtm/DTMAxisIterator;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;)V+53 jdk.translet
j  com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(Lcom/sun/org/apache/xalan/internal/xsltc/DOM;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;)V+9 java.xml@13-internal
j  com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Ljavax/xml/transform/Source;Lcom/sun/org/apache/xml/internal/serializer/SerializationHandler;Ljava/lang/String;)V+259 java.xml@13-internal
J 28630 c1 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Ljavax/xml/transform/Source;Ljavax/xml/transform/Result;)V java.xml@13-internal (240 bytes) @ 0x00007f7dee4bb244 [0x00007f7dee4bb080+0x00000000000001c4]
j  spec.benchmarks.xml.transform.Main.transform(Ljavax/xml/transform/Transformer;Ljavax/xml/transform/Source;Ljava/lang/String;I)V+18
j  spec.benchmarks.xml.transform.Main.executeWorkload()V+170
j  spec.benchmarks.xml.transform.Main.harnessMain()V+8
j  spec.harness.BenchmarkThread.runLoop(Lspec/harness/results/IterationResult;)Lspec/harness/results/LoopResult;+74
j  spec.harness.BenchmarkThread.executeIteration()Z+74
j  spec.harness.BenchmarkThread.run()V+1
v  ~StubRoutines::call_stub
V  [libjvm.so+0xddcdea]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6ea
V  [libjvm.so+0xdd9e5f]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x33f
V  [libjvm.so+0xdda07a]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xca
V  [libjvm.so+0xf20d71]  thread_entry(JavaThread*, Thread*)+0x91
V  [libjvm.so+0x16b1aea]  JavaThread::thread_main_inner()+0x26a
V  [libjvm.so+0x16ba1a7]  JavaThread::run()+0x227
V  [libjvm.so+0x16b7236]  Thread::call_run()+0xf6
V  [libjvm.so+0x13d24ee]  thread_native_entry(Thread*)+0x10e

Comments
[~tschatzl] I see, thanks for clearing that up. I will create a new bug when seeing such seemingly related GC failures in the future.
07-06-2021

[~chagedorn] At least for GC bugs, it's usually better to create a new bug and link it to the old bugs. We often end up crashing in the same places when something gets messed up. This is most likely caused by the recent broken change: JDK-8267726. That bug is going to be fixed with JDK-8268125.
07-06-2021

It's likely that this has been fixed by JDK-8224675. Before that fix, we had a bug where a load barrier for a WeakReference.get would be elided if there was as another dominating WeakReference.get call to the same oop. We haven't been able to reproduce this bug, and will close it as a CNR.
04-07-2019