JDK-6974176 : ShouldNotReachHere, instanceKlass.cpp:1426
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs19
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-08-03
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
JDK-6965184 - possible races in make_not_entrant_or_zombie
Description
VM crashed on windows-amd64, linux-i586 and solaris-sparcv9 with the following error:

[2010-07-31T14:00:56.56] # To suppress the following error report, specify this argument
[2010-07-31T14:01:04.69] # after -XX: or in .hotspotrc:  SuppressErrorAt=\oop.inline.hpp:172
[2010-07-31T14:01:04.69] #
[2010-07-31T14:01:04.69] # A fatal error has been detected by the Java Runtime Environment:
[2010-07-31T14:01:04.69] #
[2010-07-31T14:01:04.69] #  Internal Error (C:\temp\jprt\P1\B\061816.et151817\source\src\share\vm\oops\oop.inline.hpp:172), pid=165864, tid=22832
[2010-07-31T14:01:04.69] #  assert(!is_null(v)) failed: narrow oop value can never be zero
[2010-07-31T14:01:04.69] #
[2010-07-31T14:01:04.69] # JRE version: 7.0
[2010-07-31T14:01:04.69] # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b05-201007300618.et151817.hs19b05-fastdebug compiled mode windows-amd64 compressed oops)
[2010-07-31T14:01:04.69] # An error report file with more information is saved as:
[2010-07-31T14:01:04.69] # c:\local\37108.HSX.PIT.VM+windows-amd64_vm_server_comp_nsk.jvmti.testlist\results\ResultDir\em07t002\hs_err_pid165864.log

Command line was:
.../windows-amd64/bin/java -server -Xcomp -XX:+StartAttachListener "-agentlib:..." -XX:-UseGCOverheadLimit 


The linux stack was:
Stack: [0xaf53b000,0xaf5bc000],  sp=0xaf5baf50,  free space=1ffaf5bafb0k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x65e97f];;  _ZN7VMError6reportEP12outputStream+0x11ef
V  [libjvm.so+0x65ebb8];;  _ZN7VMError14report_and_dieEv+0x188
V  [libjvm.so+0x2b16fe];;  _Z15report_vm_errorPKciS0_S0_+0x3e
V  [libjvm.so+0x2b1779];;  _Z28report_should_not_reach_herePKci+0x29
V  [libjvm.so+0x37db7e];;  _ZN13instanceKlass24remove_dependent_nmethodEP7nmethod+0x3e
V  [libjvm.so+0x51daab];;  _ZN7nmethod18flush_dependenciesEP17BoolObjectClosure+0x9b
V  [libjvm.so+0x51f0fa];;  _ZN7nmethod26make_not_entrant_or_zombieEj+0x1ba
V  [libjvm.so+0x5f2202];;  _ZN14NMethodSweeper15process_nmethodEP7nmethod+0x172
V  [libjvm.so+0x5f23c0];;  _ZN14NMethodSweeper16sweep_code_cacheEv+0xd0
V  [libjvm.so+0x5f247e];;  _ZN14NMethodSweeper14possibly_sweepEv+0x6e
V  [libjvm.so+0x2769ad];;  _ZN12CompileQueue3getEv+0x1d
V  [libjvm.so+0x278fc3];;  _ZN13CompileBroker20compiler_thread_loopEv+0xc3
V  [libjvm.so+0x623088];;  _ZL21compiler_thread_entryP10JavaThreadP6Thread+0x18
V  [libjvm.so+0x627f1c];;  _ZN10JavaThread17thread_main_innerEv+0x6c
V  [libjvm.so+0x627fda];;  _ZN10JavaThread3runEv+0xaa
V  [libjvm.so+0x53bd79];;  _ZL10java_startP6Thread+0xf9
C  [libpthread.so.0+0x5832]

The solaris stack:
Stack: [0xffffffff7a900000,0xffffffff7aa00000],  sp=0xffffffff7a9ff430,  free space=3fdffffffff179b6000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x87f144];;  __1cHVMErrorOreport_and_die6M_v_+0x5ec
V  [libjvm.so+0x417190];;  __1cbCreport_should_not_reach_here6Fpkci_v_+0x48
V  [libjvm.so+0x23b910];;  __1cNinstanceKlassYremove_dependent_nmethod6MpnHnmethod__v_+0xa0
V  [libjvm.so+0x265648];;  __1cHnmethodSflush_dependencies6MpnRBoolObjectClosure__v_+0x98
V  [libjvm.so+0x72ea74];;  __1cHnmethodbAmake_not_entrant_or_zombie6MI_b_+0x3cc
V  [libjvm.so+0x804640];;  __1cONMethodSweeperQsweep_code_cache6F_v_+0x260
V  [libjvm.so+0x8043b0];;  __1cONMethodSweeperOpossibly_sweep6F_v_+0xa0
V  [libjvm.so+0x28dfb0];;  __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x378
V  [libjvm.so+0x828dac];;  __1cKJavaThreadRthread_main_inner6M_v_+0x3c
V  [libjvm.so+0x74ef1c];;  java_start+0x164
You have the wrong error message block.  It should be this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (instanceKlass.cpp:1426), pid=27085, tid=1085319488
#  Error: ShouldNotReachHere()
#
# JRE version: 7.0
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b04 compiled mode linux-amd64 compressed oops)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
Comments
EVALUATION 6974176: ShouldNotReachHere, instanceKlass.cpp:1426 Reviewed-by: kvn, twisti The changes for 6965184 reordered the flush_dependencies and post_compiled_method_unload which allowed a safepoint to happen in between. Zombie nmethods don't have their oops scanned so when flush_dependencies was run it was reading stale oops. If the oops didn't move then it would work as intended but otherwise you might get various weird failures. The fix is to restore the original order. I also added a No_SafePoint_Verifier and some logic to mark the oops as potentially stale. Tested with failing test on SQE machine that reproduced it reliably, plus nsk suites with -XX:+DeoptimizeALot -XX:CompileThreshold=100. src/share/vm/code/nmethod.cpp src/share/vm/code/nmethod.hpp
18-08-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/71faaa8e3ccc
13-08-2010
EVALUATION The changes for 6965184 reordered the flush_dependencies and the post_compiled_method_unload which allowed a safepoint to sneak in. Since the nmethod was in zombie state, the oops are no longer scanned so the flush_dependencies code was reading garbage. The fix is simply to restore the original ordering.
06-08-2010