JDK-8016188 : assert(check.is_deoptimized_frame()) failed: missed deopt
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: solaris
  • CPU: sparc
  • Submitted: 2013-06-07
  • Updated: 2019-11-04
  • Resolved: 2014-08-20
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 9
9Resolved
Related Reports
Blocks :  
JDK-8013942 - JSR 292: assert(type() == T_OBJECT) failed: type check
Relates :  
JDK-8233428 - Test fails with assert(check.is_deoptimized_frame()) failed: missed deopt
Description
#
#  Internal Error (src/share/vm/runtime/frame.cpp:334), pid=5858, tid=5
#  assert(check.is_deoptimized_frame()) failed: missed deopt
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b92) (build 1.8.0-ea-fastdebug-b92)
# Java VM: Java HotSpot(TM) Server VM (25.0-b36-internal-201306061631.cthaling.8014246-fastdebug compiled mode solaris-sparc )
# Core dump written. Default location: ResultDir/breakpointOtherStratum/core or core.5858
#
# 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 (0x001adc00):  VMThread [stack: 0xfc880000,0xfc900000] [id=5]

Stack: [0xfc880000,0xfc900000],  sp=0xfc8feaf0,  free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1027344]  void VMError::report_and_die()+0x85c;;  __1cHVMErrorOreport_and_die6M_v_+0x85c
V  [libjvm.so+0x65f734]  void report_vm_error(const char*,int,const char*,const char*)+0x74;;  __1cPreport_vm_error6Fpkci11_v_+0x74
V  [libjvm.so+0x71a158]  void frame::deoptimize(JavaThread*)+0x324;;  __1cFframeKdeoptimize6MpnKJavaThread__v_+0x324
V  [libjvm.so+0x687168]  void Deoptimization::deoptimize(JavaThread*,frame,RegisterMap*)+0x1c8;;  __1cODeoptimizationKdeoptimize6FpnKJavaThread_nFframe_pnLRegisterMap__v_+0x1c8
V  [libjvm.so+0xf7ae28]  void JavaThread::deoptimize()+0x26c;;  __1cKJavaThreadKdeoptimize6M_v_+0x26c
V  [libjvm.so+0x1055f64]  void VM_DeoptimizeAll::doit()+0x7c;;  __1cQVM_DeoptimizeAllEdoit6M_v_+0x7c
V  [libjvm.so+0x10558a0]  void VM_Operation::evaluate()+0xe0;;  __1cMVM_OperationIevaluate6M_v_+0xe0
V  [libjvm.so+0x1053050]  void VMThread::evaluate_operation(VM_Operation*)+0x1ec;;  __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x1ec
V  [libjvm.so+0x10537cc]  void VMThread::loop()+0x4c4;;  __1cIVMThreadEloop6M_v_+0x4c4
V  [libjvm.so+0x1052abc]  void VMThread::run()+0x10c;;  __1cIVMThreadDrun6M_v_+0x10c
V  [libjvm.so+0xd4030c]  java_start+0x174;;  java_start+0x174

VM_Operation (0xd9eef364): DeoptimizeAll, mode: safepoint, requested by thread 0x00bd7c00


Note, old bug 7081939 was for old implementation of jsr292.
Comments
The bug has not appeared since the beginning of May. Tried to reproduce the bug with jdk9 b26 on one of the machines where the bug originally appeared. I could not reproduce it.
20-08-2014
[~twisti] Yes, the JDK-8017519 was converted into the INTJDK-7611532.
18-08-2014
Thank you Serguei for checking. Let's get back to this bug then when you have fixed JDK-8017519.
07-10-2013
Chris, I can not reproduce both this issue and the blocking JDK-8013942, so it is hard to prove if it is JVMTI related. The stack trace itself does not seem the JVMTI related. The JDK-8013942 is also blocked on the JDK-8017519. I will not wonder if after fixing the JDK-8017519 we discover other two issues not reproducible anymore.
07-10-2013
Since the bug is blocked by other bugs that are to be deferred from JDK8, SQE is ok to defer this bug from JDK8.
07-10-2013
8-defer-request: This bug is blocked on JDK-8013942 which has been deferred. Until JDK-8013942 is fixed, this bug can't be fixed. It's also an MLVM test, and does not impact many tests. Defer to a JDK8 update release.
07-10-2013
Additionally I have asked Serguei to take a look also to verify it's not JVMTI related.
04-10-2013
This bug is either blocked by or even a duplicate of JDK-8013942. Every run of breakpointOtherStratum hits this assert: debugee.stdout> # Internal Error (/HUDSON/workspace/2-build-solaris-sparc/jdk8/4590/hotspot/src/share/vm/runtime/stackValue.hpp:64), pid=23253, tid=5 debugee.stdout> # assert(type() == T_OBJECT) failed: type check
15-07-2013
RULE vm/mlvm/meth/func/jdi/breakpointOtherStratum Crash any
21-06-2013