JDK-8043125 : compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u20,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2014-05-14
  • Updated: 2021-06-21
  • Resolved: 2014-11-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 8 JDK 9
8u291Fixed 9 b40Fixed
Related Reports
Relates :  
JDK-8066173 - compiler/types/correctness/OffTest.java failed with assert
Description
compiler/types/correctness/CorrectnessTest.java failed on windows x64 only  for jdk9/hs/nightly:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\\jprt\\T\\P1\\210633.drchase\\s\\src\\share\\vm\\oops/methodData.hpp:1934), pid=18720, tid=9828
#  assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b12) (build 1.9.0-ea-fastdebug-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-201405092106.drchase.8037816-fastdebug mixed mode windows-amd64 compressed oops)
# Core dump written. Default location: C:\\local\\aurora\\sandbox\\results\\workDir\\compiler\\types\\correctness\\CorrectnessTest\\hs_err_pid18720.mdmp
#
Unsupported internal testing APIs have been used.
Comments
8u backport blocked by JDK-8258774, need to export _extra_data_lock from MethodData.
21-06-2021
compiler/types/correctness/ tests do cover this issue w/ some probability.
30-10-2014
noreg-hard: to reproduce this issue, we need to switch from compiler thread to whitebox thread/safepoint after read dp_src->tag(): int tag = dp_src->tag(); if (tag != DataLayout::arg_info_data_tag) { memcpy(dp_dst, dp_src, ((intptr_t)MethodData::next_extra(dp_src)) - ((intptr_t)dp_src)); } switch(tag) { case DataLayout::speculative_trap_data_tag: { ciSpeculativeTrapData* data_dst = new ciSpeculativeTrapData(dp_dst); SpeculativeTrapData* data_src = new SpeculativeTrapData(dp_src);
30-10-2014
Same ILW, but this is a nightly bug -> HLH=P2
07-10-2014
Holding a mutex while submitting a VM operation is potentially deadlock prone - you'd need to carefully analyse usage of that lock.
06-10-2014
suggested fix: --- a/src/share/vm/prims/whitebox.cpp Fri Sep 12 04:22:19 2014 -0700 +++ b/src/share/vm/prims/whitebox.cpp Sat Oct 04 22:54:39 2014 +0400 @@ -514,6 +514,7 @@ for (int i = 0; i < arg_count; i++) { mdo->set_arg_modified(i, 0); } + MutexLockerEx mu(mdo->extra_data_lock()); VM_WhiteBoxCleanMethodData op(mdo); VMThread::execute(&op); } trying to write a small testcase to verify it
04-10-2014
This bug is actually caused by a WB api call that the test uses. That WB api call triggers a VM operation that unconditionally cleans all profile entries. If there's a compilation on the fly, a safepoint may happen during SpeculativeTrapData translation and entries being translated are then removed. This really is a WB api bug. The WB api call should guarantee that there's no compilation on the fly and that there won't be any for the duration of the WB api VM operation. Alternatively, running with -XX:-BackgroundCompilation should fix the test.
07-08-2014
RULE compiler/types/correctness/OffTest.java Crash Internal Error ...methodData.hpp...assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type
07-06-2014
New failure in RT Nightly: JDK: Java(TM) SE Runtime Environment 1.9.0 b16 (1.9.0-ea-fastdebug-b16) VM:Java HotSpot(TM) 64-Bit Server VM 1.9.0 b0 (1.9.0-internal-201406061312.ctornqvi.hs-rt-fastdebug) Host: spb23177, Intel x86 2893 MHz, 2 cores, 11G, Solaris / Solaris 11, i86pc ;; Using jvm: "jdk/nightly/fastdebug/rt_baseline/solaris-amd64/jre/lib/amd64/server/libjvm.so" # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (src/share/vm/oops/methodData.hpp:1955), pid=12638, tid=9 # assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type # # JRE version: Java(TM) SE Runtime Environment (9.0-b16) (build 1.9.0-ea-fastdebug-b16) # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-201406061312.ctornqvi.hs-rt-fastdebug mixed mode solaris-amd64 compressed oops) # Core dump written. Default location: compiler/types/correctness/OffTest/core or core.12638 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x000000000075b800): JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=9, stack(0xfffffd7ffca28000,0xfffffd7ffcb28000)] Stack: [0xfffffd7ffca28000,0xfffffd7ffcb28000], sp=0xfffffd7ffcb24210, free space=1008k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x2a2acb3] void VMError::report(outputStream*)+0x937;; __1cHVMErrorGreport6MpnMoutputStream__v_+0x937 V [libjvm.so+0x2a2c279] void VMError::report_and_die()+0x579;; __1cHVMErrorOreport_and_die6M_v_+0x579 V [libjvm.so+0x108dfdb] void report_vm_error(const char*,int,const char*,const char*)+0x55f;; __1cPreport_vm_error6Fpkci11_v_+0x55f V [libjvm.so+0xdc0d08] void ciMethodData::load_data()+0xc20;; __1cMciMethodDataJload_data6M_v_+0xc20 V [libjvm.so+0xda761a] bool ciMethod::ensure_method_data(methodHandle)+0x1ba;; __1cIciMethodSensure_method_data6MnMmethodHandle__b_+0x1ba V [libjvm.so+0xda7b0c] bool ciMethod::ensure_method_data()+0x330;; __1cIciMethodSensure_method_data6M_b_+0x330 V [libjvm.so+0xf3a48a] Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool,bool,bool)+0x986;; __1cHCompile2t6MpnFciEnv_pnKC2Compiler_pnIciMethod_ibbb_v_+0x986 V [libjvm.so+0xcd95ee] void C2Compiler::compile_method(ciEnv*,ciMethod*,int)+0x1b6;; __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0x1b6 V [libjvm.so+0xf67c0a] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4ea;; __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0x4ea V [libjvm.so+0xf6719d] void CompileBroker::compiler_thread_loop()+0x3c5;; __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x3c5 V [libjvm.so+0x287f769] void JavaThread::thread_main_inner()+0x521;; __1cKJavaThreadRthread_main_inner6M_v_+0x521 V [libjvm.so+0x287ee7d] void JavaThread::run()+0x8a1;; __1cKJavaThreadDrun6M_v_+0x8a1 V [libjvm.so+0x23ec9b2] java_start+0x1ce;; java_start+0x1ce C [libc.so.1+0x12257d] _thrp_setup+0xa5;; _thrp_setup+0xa5 C [libc.so.1+0x122820] _lwp_start+0x0;; _lwp_start+0x0
07-06-2014
It failed today during my manual jtreg testing on lab machine (solaris-x64) but I was not able to reproduce it. I ran jtreg with -javaoptions:'-XX:-TieredCompilation' compiler (only open). Unfortunately jtreg did not preserve hs_err file. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/methodData.hpp:1955 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (src/share/vm/oops/methodData.hpp:1955), pid=8750, tid=41 # assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type # # JRE version: Java(TM) SE Runtime Environment (9.0-b15) (build 1.9.0-ea-fastdebug-b15) # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-fastdebug mixed mode solaris-amd64 compressed oops) # Failed to write core dump. 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: # test/JTwork/scratch/hs_err_pid8750.log
04-06-2014
ILW=Assert, potential crash; once in nightly, none=MLH=P4
14-05-2014
Current thread (0x00000000168af800): JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=9828, stack(0x00000000171d0000,0x00000000172d0000)] Stack: [0x00000000171d0000,0x00000000172d0000] [error occurred during error reporting (printing stack bounds), id 0xc0000005] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x48fb3a] os::platform_print_native_stack+0x5a;; ?platform_print_native_stack@os@@SA_NPEAVoutputStream@@PEAXPEADH@Z+0x5a V [jvm.dll+0x3a0130] VMError::report+0x950;; ?report@VMError@@AEAAXPEAVoutputStream@@@Z+0x950 V [jvm.dll+0x3a0dda] VMError::report_and_die+0x44a;; ?report_and_die@VMError@@QEAAXXZ+0x44a V [jvm.dll+0x3c7fe6] report_error+0x36;; ?report_error@@YAXPEAVThread@@KPEAEPEAX2@Z+0x36 V [jvm.dll+0x3ccd15] topLevelExceptionFilter+0x395;; ?topLevelExceptionFilter@@YAJPEAU_EXCEPTION_POINTERS@@@Z+0x395 V [jvm.dll+0x91d4af] `java_start'::`1'::filt$0+0xf;; ?filt$0@?0??java_start@@YAIPEAVThread@@@Z@4HA+0xf C [msvcr100.dll+0x712e3] V [jvm.dll+0x91cbad] __GSHandlerCheck_SEH+0x75;; __GSHandlerCheck_SEH+0x75 C [ntdll.dll+0x9921d] C [ntdll.dll+0x55b5b] C [ntdll.dll+0x983de] V [jvm.dll+0x313ed1] os::is_first_C_frame+0x21;; ?is_first_C_frame@os@@SA_NPEAVframe@@@Z+0x21 Current CompileTask: C2: 2105 365 4 scenarios.ClassIsInstance::run (144 bytes)
14-05-2014