United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8014052 : JSR292: assert(end_offset == next_offset) failed: matched ending

Details
Type:
Bug
Submit Date:
2013-05-07
Status:
Closed
Updated Date:
2014-09-04
Project Name:
JDK
Resolved Date:
2013-06-04
Component:
hotspot
OS:
Sub-Component:
compiler
CPU:
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs25,7u60
Fixed Versions:
hs25 (b36)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
;; Using jvm: "/export/local/aurora/sandbox/sca/vmsqe/jdk/pit/2013-05-03-151437.amurillo.hs25-b31-snapshot/fastdebug/solaris-sparc/jre/lib/sparc/client/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/151437.amurillo/s/src/share/vm/oops/constantPool.hpp:621), pid=13409, tid=2
#  assert(end_offset == next_offset) failed: matched ending
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b87) (build 1.8.0-ea-fastdebug-b87)
# Java VM: Java HotSpot(TM) Client VM (25.0-b31-internal-201305031514.amurillo.hs25-b31-snapshot-fastdebug compiled mode solaris-sparc )
# Core dump written. Default location: /export/local/aurora/sandbox/results/ResultDir/redefineClassInBootstrap/core or core.13409
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Stack: [0xfdb20000,0xfdba0000],  sp=0xfdb9e6e8,  free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc08ad8]  void VMError::report_and_die()+0x870;;  __1cHVMErrorOreport_and_die6M_v_+0x870
V  [libjvm.so+0x452464]  void report_vm_error(const char*,int,const char*,const char*)+0x74;;  __1cPreport_vm_error6Fpkci11_v_+0x74
V  [libjvm.so+0x44b650]  int ConstantPool::invoke_dynamic_argument_count_at(int)+0x164;;  __1cMConstantPoolbGinvoke_dynamic_argument_count_at6Mi_i_+0x164
V  [libjvm.so+0x442dd8]  oop ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle,int,Thread*)+0x29c;;  __1cMConstantPoolbJresolve_bootstrap_specifier_at_impl6FnSconstantPoolHandle_ipnGThread__nDoop__+0x29c
V  [libjvm.so+0x8a559c]  void LinkResolver::resolve_invokedynamic(CallInfo&,constantPoolHandle,int,Thread*)+0x310;;  __1cMLinkResolverVresolve_invokedynamic6FrnICallInfo_nSconstantPoolHandle_ipnGThread__v_+0x310
V  [libjvm.so+0x8a49e8]  void LinkResolver::resolve_invoke(CallInfo&,Handle,constantPoolHandle,int,Bytecodes::Code,Thread*)+0x15c;;  __1cMLinkResolverOresolve_invoke6FrnICallInfo_nGHandle_nSconstantPoolHandle_inJBytecodesECode_pnGThread__v_+0x15c
V  [libjvm.so+0x61a054]  void InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x65c;;  __1cSInterpreterRuntimeVresolve_invokedynamic6FpnKJavaThread__v_+0x65c
j  vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.INDIFY_Dummy0.invokeTarget()Z+18
v  ~StubRoutines::call_stub
V  [libjvm.so+0x62e358]  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x744;;  __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x744
V  [libjvm.so+0xa71ee4]  oop Reflection::invoke(instanceKlassHandle,methodHandle,Handle,bool,objArrayHandle,BasicType,objArrayHandle,bool,Thread*)+0x2408;;  __1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_bnOobjArrayHandle_nJBasicType_4bpnGThread__nDoop__+0x2408
V  [libjvm.so+0xa73330]  oop Reflection::invoke_method(oop,Handle,objArrayHandle,Thread*)+0x6c4;;  __1cKReflectionNinvoke_method6FnDoop_nGHandle_nOobjArrayHandle_pnGThread__1_+0x6c4
V  [libjvm.so+0x759ce0]  JVM_InvokeMethod+0x590;;  JVM_InvokeMethod+0x590
C  [libjava.so+0xf774]  Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x18;;  Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x18
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+56
j  vm.mlvm.indy.func.jvmti.share.IndyRedefineTest.run()Z+65
j  vm.mlvm.share.MlvmTest.runMlvmTest(Ljava/lang/Class;)Z+113
j  vm.mlvm.share.MlvmTest.launch()V+135
j  vm.mlvm.share.MlvmTest.launch([Ljava/lang/String;)V+4
j  vm.mlvm.indy.func.jvmti.share.IndyRedefineTest.main([Ljava/lang/String;)V+1
v  ~StubRoutines::call_stub
V  [libjvm.so+0x62e358]  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x744;;  __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x744
V  [libjvm.so+0x66a0c8]  void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*)+0x980;;  __1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_+0x980
V  [libjvm.so+0x69465c]  jni_CallStaticVoidMethod+0x580;;  jni_CallStaticVoidMethod+0x580
C  [libjli.so+0x6fb4]  JavaMain+0x76c;;  JavaMain+0x76c
                                    

Comments
I believe the compiler team is improving invoke dynamic to work with redefineclasses.
                                     
2013-05-07
Serguei, can you take care of this one?
                                     
2013-05-07
Sure.
I've created the same bug and assigned it to myself but this one was created 2 minutes earlier. :)
So that David closed my instance as a dup.
                                     
2013-05-07
Ok, I see what the issue is: call to the finalize_operands_merge() must be unconditional.
With my local fix the test redefineClassInBootstrap is passed on solaris-sparc.
The test mergeCP_indy2same_b  is failing with a different pattern now, but the original pattern of this bug is gone now.
The behavior of these tests on solaris-i586/x64 is different.
                                     
2013-05-31
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e7d29a019a3c
User:  sspitsyn
Date:  2013-06-04 05:05:55 +0000

                                     
2013-06-04
URL:   http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7d29a019a3c
User:  amurillo
Date:  2013-06-07 19:51:24 +0000

                                     
2013-06-07
7u60-critical-request justification:

This bug fix is better to be in the release because it is a part of the JSR-292 support
in the JVMTI HotSwap API (includes RedefineClasses, RetransformClasses and PopFrame).

This bug is one of 12 bug fixes that depend on each other and must be integrated
in the order:
  https://jbs.oracle.com/bugs/browse/JDK-7194607
  https://jbs.oracle.com/bugs/browse/JDK-8005128
  https://jbs.oracle.com/bugs/browse/JDK-8006542
  https://jbs.oracle.com/bugs/browse/JDK-8006546
  https://jbs.oracle.com/bugs/browse/JDK-8006731
  https://jbs.oracle.com/bugs/browse/JDK-8008511
  https://jbs.oracle.com/bugs/browse/JDK-8007037
  https://jbs.oracle.com/bugs/browse/JDK-8014288
  https://jbs.oracle.com/bugs/browse/JDK-8013945
  https://jbs.oracle.com/bugs/browse/JDK-8014052
  https://jbs.oracle.com/bugs/browse/JDK-7187554
  https://jbs.oracle.com/bugs/browse/JDK-8023004

All the fixes above have been already integrated into the JDK 8
and tested in the hotspot-rt nightly for several months.

Risk: low
  The fixes touch the JVMTI HotSwap API that includes RedefineClasses, RetransformClasses and PopFrame.
  The risk is only to introduce regressions in this part of the JVMTI implementation.
  This impacts only the debugging and profiling tools that use the JVMTI HotSwap feature.
  There are very small chances for regressions to sneak into the class file
  constant pool processing and method handles implementation.

Webrevs and reviewers:
  The 7u60 webrevs location is:
    http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/7u_port/

  The fixes above were already passed the review process before integration
  into JDK 8. The reviewers were: twisti, jrose, coleenp, dholmes, etc.
  The 7u60 edition of fixes must be reviewed at least by jrose and twisti.

Level of effort:
  All fixes need a secondary review phase after rebase from jdk8 to 7u60 repository.

Testing coverage:
  The folllowing test suites must be run to ensure correctness of the fixes:
    JTREG tests: com/sun/jdi, java/lang/instrument
    NSK tests: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist

Result of not integrating:
  The users will not be able to use HotSwap technology for debuging and profiling
  Java code that depends on the JSR-292 implementation.
  In that case the integration of these fixes will have to be requested/escalated
  in 7 updates by the tool vendors and/or customers.

                                     
2014-01-10



Hardware and Software, Engineered to Work Together