JDK-6990266 : JSR 292 VM crash in Klass::is_subclass_of()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs20
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-10-07
  • Updated: 2012-02-01
  • Resolved: 2011-04-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 7
7Resolved
Related Reports
Duplicate :  
JDK-7018355 - JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
Relates :  
JDK-6990587 - JRuby test/test_rexml_document.rb fails with NPE on SPARC
Description
VM crashed in Multi-language VM tests:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfe8a1510, pid=7914, tid=2
#
# JRE version: 7.0
# Java VM: Java HotSpot(TM) Server VM (20.0-b01 compiled mode solaris-x86 )
# Problematic frame:
# V  [libjvm.so+0x8a1510]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Instructions: (pc=0xfe8a1510)
0xfe8a1500:   55 8b ec 8b 55 08 8d 42 f8 8b 4d 0c 3b c1 74 1f
0xfe8a1510:   8b 42 38 85 c0 74 14 3b c1 74 09 8b 40 40 85 c0 
;; fe8a1500 55                      push   %ebp               
;; fe8a1501 8b ec                   mov    %esp,%ebp          
;; fe8a1503 8b 55 08                mov    0x8(%ebp),%edx     
;; fe8a1506 8d 42 f8                lea    0xfffffff8(%edx),%eax
;; fe8a1509 8b 4d 0c                mov    0xc(%ebp),%ecx       
;; fe8a150c 3b c1                   cmp    %ecx,%eax            
;; fe8a150e 74 1f                   je     0xfe8a152f           
;; ---------------                                              
;; fe8a1510 8b 42 38                mov    0x38(%edx),%eax      
;; fe8a1513 85 c0                   test   %eax,%eax            
;; fe8a1515 74 14                   je     0xfe8a152b           
;; fe8a1517 3b c1                   cmp    %ecx,%eax            
;; fe8a1519 74 09                   je     0xfe8a1524           
;; fe8a151b 8b 40 40                mov    0x40(%eax),%eax      
;; fe8a151e 85 c0                   test   %eax,%eax            
;;                                                              
Stack: [0xfde7f000,0xfdecf000],  sp=0xfdece588,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8a1510];;  bool Klass::is_subclass_of(klassOopDesc*)const+0x10 
V  [libjvm.so+0x943551];;  methodOopDesc*MethodHandles::decode_method(oopDesc*,klassOopDesc*&,int&)+0x65
V  [libjvm.so+0xa156cd];;  char*SharedRuntime::generate_wrong_method_type_message(JavaThread*,oopDesc*,oopDesc*)+0x969
V  [libjvm.so+0x700302];;  void InterpreterRuntime::throw_WrongMethodTypeException(JavaThread*,oopDesc*,oopDesc*)+0x52
j  sun.dyn.CallSiteImpl.makeSite(Ljava/dyn/MethodHandle;Ljava/lang/String;Ljava/dyn/MethodType;Ljava/lang/Object;Lsun/dyn/MemberName;I)Ljava/dyn/CallSite;+63
j  sun.dyn.MethodHandleNatives.makeDynamicCallSite(Ljava/dyn/MethodHandle;Ljava/lang/String;Ljava/dyn/MethodType;Ljava/lang/Object;Lsun/dyn/MemberName;I)Ljava/dyn/CallSite;+8
v  ~StubRoutines::call_stub                                                                                                                                                   
V  [libjvm.so+0x15c8ea];;  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x53e                                                             
V  [libjvm.so+0x15cca8];;  void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x18
V  [libjvm.so+0x210070];;  void JavaCalls::call_static(JavaValue*,KlassHandle,symbolHandle,symbolHandle,JavaCallArguments*,Thread*)+0x74                                       
V  [libjvm.so+0xa92922];;  Handle SystemDictionary::make_dynamic_call_site(Handle,symbolHandle,methodHandle,Handle,methodHandle,int,Thread*)+0x506                             
V  [libjvm.so+0x701921];;  void InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x895                  

Please see more details in comments.
Comments
EVALUATION It's not reproducible anymore but it's very likely a duplicate of 7018355.
20-04-2011
EVALUATION Since 7018355 happens from time to time when trying to reproduce this one we should first fix 7018355 and then get back to this one.
28-03-2011
EVALUATION I tried to reproduce the bug on intelsdv40, terminus and vmsqe-t2000c but without any luck. The fact that the testcase runs for a very long time (and produces a very high load) makes it even more difficult to reproduce it. Did this bug happen again with a recent promotion (or similar) testing?
22-03-2011
EVALUATION The following test failed on solaris-sparcv9 during JDK7 b126 promotion testing: vm/mlvm/indy/stress/java/loopsAndThreads Test output: # SIGSEGV (0xb) at pc=0xfeb18458, pid=17247, tid=326 # # JRE version: 7.0-b126 # Java VM: Java HotSpot(TM) Server VM (20.0-b06 mixed mode solaris-sparc ) # Problematic frame: # V [libjvm.so+0x718458] bool Klass::is_subclass_of(klassOopDesc*)const+0xc Stack: [0xa4300000,0xa4380000], sp=0xa437e738, free space=505k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x718458] bool Klass::is_subclass_of(klassOopDesc*)const+0xc;; bool Klass::is_subclass_of(klassOopDesc*)const+0xc j vm.mlvm.indy.stress.java.loopsAndThreads.INDIFY_Test.runThread()Z+33 j vm.mlvm.share.MultiThreadedTest$1.run()V+6 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x1702b4] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x2a0;; void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x2a0 V [libjvm.so+0x210168] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*)+0x190;; void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*)+0x190 V [libjvm.so+0x224854] void thread_entry(JavaThread*,Thread*)+0x11c;; void thread_entry(JavaThread*,Thread*)+0x11c V [libjvm.so+0x8f8e2c] void JavaThread::thread_main_inner()+0x44;; void JavaThread::thread_main_inner()+0x44 V [libjvm.so+0x809fa0] java_start+0x270;; java_start+0x270 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j vm.mlvm.indy.stress.java.loopsAndThreads.INDIFY_Test.runThread()Z+33 j vm.mlvm.share.MultiThreadedTest$1.run()V+6 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub Results are at: http://vmsqe.russia.sun.com/execution/results/JDK7/ADHOC/VM/2011-01-31_01/vm/solaris-sparcv9/server/mixed/solaris-sparcv9_vm__server_mixed_vm.mlvm.testlist/analysis.html
01-02-2011
EVALUATION Yes, the newer version is available and it's still crashing: Please look for 'loopsAndThreads' at the following page: http://vmsqe.russia.sun.com/execution/results/JDK7/ADHOC/VM/2011-01-31_01/vm/solaris-sparcv9/server/mixed/solaris-sparcv9_vm__server_mixed_vm.mlvm.testlist/analysis.html
01-02-2011
EVALUATION I just came back to this bug and the testcase does not work anymore because java.dyn.InvokeDynamic has been removed: - IndyRedefineClass.c, 37: Setting redefined class name to vm/mlvm/indy/func/jvmti/redefineClassInBootstrap/Dummy0 - IndyRedefineClass.c, 31: Setting redefine trigger method name to redefineNow Original class: registering a bootstrap method # ERROR: Caught an exception: java.lang.IllegalAccessError: tried to access class java.dyn.InvokeDynamic from class vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Dummy0 at vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Dummy0.invokeTarget(Dummy0.java:28) at vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Test.run(Test.java:19) at vm.mlvm.share.MlvmTest.runMlvmTest(MlvmTest.java:51) at vm.mlvm.share.MlvmTest.launch(MlvmTest.java:28) at vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Test.main(Test.java:32) ### TRACE 0: The test took 3448 ms ### TRACE 0: TEST FAILED Is there a newer version of the test available?
18-01-2011
EVALUATION The "actual" argument coming in is actually a thread pointer, but I think this is just coincidence: [16] java_dyn_MethodHandle::is_subclass(klass = (nil)), line 819 in "javaClasses.hpp" [17] MethodHandles::decode_method(x = 0x8082000, receiver_limit_result = (nil), decode_flags_result = 0), line 303 in "methodHandles.cpp" [18] SharedRuntime::generate_wrong_method_type_message(thread = 0x8082000, required = 0xe4d1f4a8, actual = 0x8082000), line 1677 in "sharedRuntime.cpp" [19] InterpreterRuntime::throw_WrongMethodTypeException(thread = 0x8082000, required = 0xe4d1f4a8, actual = 0x8082000), line 315 in "interpreterRuntime.cpp" Running with -Xint throws the exception without any problem so I guess this is related to the deoptimization happening: Uncommon trap occurred in vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Dummy0::bootstrap (@0xfa56a22c) thread=1 reason=unloaded action=reinterpret unloaded_class_index=3 unresolved class: java/lang/StringBuilder DEOPT PACKING thread 0x08082000 Compiled frame (sp=0x080464c0 unextended sp=0x080464c0, fp=0xe4d01550, pc=0xfa56a22c) 10820 616 nmethod vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Dummy0::bootstrap (56 bytes) Virtual frames (innermost first): 0 - frame( sp=0x080464c0, unextended_sp=0x080464c0, fp=0xe4d01550, pc=0xfa56a22c) vm.mlvm.indy.func.jvmti.redefineClassInBootstrap.Dummy0.bootstrap(Dummy0.java:14) - new @ bci 3 Created vframeArray 0x0837ff78 DEOPT UNPACKING thread 0x08082000 vframeArray 0x0837ff78 mode 2 {method} 'bootstrap' '(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;)Ljava/dyn/CallSite;' in 'vm/mlvm/indy/func/jvmti/redefineClassInBootstrap/Dummy0' - new @ bci 3 sp = 0x080464b4 Maybe this is a duplicate of 6990587.
08-10-2010