JDK-8029351 : assert(bt != T_OBJECT) failed: Guard is incorrect in VM:defmeth
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-29
  • Updated: 2014-01-14
  • Resolved: 2013-12-13
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 Other
8Fixed 9Fixed hs25Fixed
Related Reports
Relates :  
JDK-7184997 - NPG: assert(bt != T_OBJECT) failed: Guard is incorrect
Relates :  
JDK-8016839 - JSR292: AME instead of IAE when calling a method
Description
some vm defmeth tests failed w/ 'assert(bt != T_OBJECT) failed: Guard is incorrect' during adhoc for private build w/ fixes for JDK-8016839

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/215600.drchase/s/hotspot/src/share/vm/oops/generateOopMap.cpp:1874), pid=4194, tid=140098016376576
#  assert(bt != T_OBJECT) failed: Guard is incorrect
#
# JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-201311272156.drchase.8016839-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b61-fastdebug mixed mode linux-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
#
# 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 (0x00007f6b200bf800):  VMThread [stack: 0x00007f6b1c6ff000,0x00007f6b1c800000] [id=4205]

Stack: [0x00007f6b1c6ff000,0x00007f6b1c800000],  sp=0x00007f6b1c7fca80,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xf615ca]  VMError::report_and_die()+0x2da
V  [libjvm.so+0x6e0d64]  report_vm_error(char const*, int, char const*, char const*)+0x84
V  [libjvm.so+0x8311e1]  GenerateOopMap::do_ldc(int)+0x291
V  [libjvm.so+0x832b38]  GenerateOopMap::interp_bb(BasicBlock*)+0x1b8
V  [libjvm.so+0x833764]  GenerateOopMap::do_interpretation()+0xf4
V  [libjvm.so+0x833e5e]  GenerateOopMap::compute_map(Thread*)+0x39e
V  [libjvm.so+0xce3c2e]  OopMapForCacheEntry::compute_map(Thread*)+0xfe
V  [libjvm.so+0xce4c05]  OopMapCacheEntry::fill(methodHandle, int)+0x535
V  [libjvm.so+0xce6769]  OopMapCache::lookup(methodHandle, int, InterpreterOopMap*)+0xd09
V  [libjvm.so+0x8bf4b2]  InstanceKlass::mask_for(methodHandle, int, InterpreterOopMap*)+0x52
V  [libjvm.so+0xc5173b]  Method::mask_for(int, InterpreterOopMap*)+0x7b
V  [libjvm.so+0x7a72ab]  frame::oops_interpreted_do(OopClosure*, CLDToOopClosure*, RegisterMap const*, bool)+0x6ab
V  [libjvm.so+0xed95cd]  JavaThread::oops_do(OopClosure*, CLDToOopClosure*, CodeBlobClosure*)+0x1ad
V  [libjvm.so+0xed68f5]  Threads::oops_do(OopClosure*, CLDToOopClosure*, CodeBlobClosure*)+0x35
V  [libjvm.so+0xdfbefb]  SharedHeap::process_strong_roots(bool, bool, SharedHeap::ScanningOption, OopClosure*, CodeBlobClosure*, KlassClosure*)+0x25b
V  [libjvm.so+0x826b58]  GenCollectedHeap::gen_process_strong_roots(int, bool, bool, bool, SharedHeap::ScanningOption, OopsInGenClosure*, bool, OopsInGenClosure*, KlassClosure*)+0x78
V  [libjvm.so+0x6f085e]  DefNewGeneration::collect(bool, bool, unsigned long, bool)+0x47e
V  [libjvm.so+0x828cdd]  GenCollectedHeap::do_collection(bool, bool, unsigned long, bool, int)+0x78d
V  [libjvm.so+0x627eef]  GenCollectorPolicy::satisfy_failed_allocation(unsigned long, bool)+0x10f
V  [libjvm.so+0xf625c1]  VM_GenCollectForAllocation::doit()+0xd1
V  [libjvm.so+0xf8b1c5]  VM_Operation::evaluate()+0xa5
V  [libjvm.so+0xf88be7]  VMThread::evaluate_operation(VM_Operation*)+0x137
V  [libjvm.so+0xf896e0]  VMThread::loop()+0x660
V  [libjvm.so+0xf89910]  VMThread::run()+0xb0
V  [libjvm.so+0xcf8488]  java_start(Thread*)+0x108
Comments
http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=331327.JAVASE_EMBEDDED_NIGHTLY-124 RULE vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_invoke_noredefine Crash Internal Error ...generateOopMap.cpp...assert(bt != T_OBJECT) failed: Guard is incorrect RULE vm/runtime/defmeth/scenarios/StaticMethods_v52_none_invoke_noredefine Crash Internal Error ...generateOopMap.cpp...assert(bt != T_OBJECT) failed: Guard is incorrect RULE vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_redefine Crash Internal Error ...generateOopMap.cpp...assert(bt != T_OBJECT) failed: Guard is incorrect
16-12-2013
Release team: Approved for fixing
12-12-2013
SQE is ok to integrate in JDK8
12-12-2013
ILW=MHH => P2 Impact: High because of the crash in debug builds, infinite loop in product builds. Likelihood: Medium as you need to be writing code with MethodHandles Workaround: None, as this happens out of the box Justification: In a release build the bug manifests itself as an infinite loop. Risk assessment: very, very low. The fix is a straightforward fix to an if statement to confirm that a bytecode 'ldc' constant is an object. Not fixing this means that MethodHandles which are improperly created will crash the JVM. The JVM should not crash with improperly created MHs which could confuse language designers. The crash in DefMethods testing are examples of this and are meant to test the error path. Testing: tested with jtreg and ute-vm.quick.testlist and 1000 repetitions of defmeth.
12-12-2013
Release team: Need justification, risk assessment and testing done
11-12-2013
since more tests are affected and issue happens OOB, likelihood is High ILW=MHH => P2
09-12-2013
in PIT of hs25-b62 for jdk8-b120 a several defmeth tests trigger the same assert, these runs were w/o AggressiveOpts, Xcomp and DeoptimizeALot, just '-server -Xmixed' and '-client -Xmixed'.
09-12-2013
Release team: Lacks justification + new target release.
06-12-2013
It's far from a sure-fire reproducer; adding -Xcomp makes it happen more often, removing -XX:+DeoptimizeALot makes it happen less often. It appears to affect release builds, and occurs there in the form of a multi-threaded infinite loop that requires a hard kill to make it go away. Against this having a higher priority is (1) Removing -XX:+AggressiveOpts seems to make it not happen, at least in a release build, even with -XX:+DeoptimizeALot and -Xcomp . That seems to be the trigger. (2) it requires borked bytecodes (the test that sometimes fails expects a VerifyError, and complains because it only sees an IllegalAccessError) so it is nowhere near common case: Test2_C_C_m : FAILED Expected exception java.lang.VerifyError, got: class java.lang.IllegalAccessError: no such method: C.m()int/invokeVirtual (3) Note that the expected exception is apparently VerifyError (this was run with the most recent copy of defmeth that I could find), so unless this changes, we should not even be seeing these inputs to the compiler. (4) Note that this is incorrect compilation of an error path -- it's not clear that this would normally get compiled without flags designed to provoke aggressive compilation.
05-12-2013
Does this duplicate with a binary before (or without) the fix for 8016839? I recommend giving this to David initially to determine that.
01-12-2013
ILW=MMH=>P3
29-11-2013