JDK-8065740 : compiler/codecache/OverflowCodeCacheTest.java fails with SIGSEGV
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-11-24
  • Updated: 2014-11-26
  • Resolved: 2014-11-26
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
Duplicate :  
Relates :  
Description
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfffffd7ffd6e9ea7, pid=17374, tid=27
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-201411220122.vkozlov.8065618-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-fastdebug-201411220122.vkozlov.8065618-b00 compiled mode solaris-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0xee9ea7]  bool NMethodIterator::next_nmethod()+0x547

Stack: [0xfffffd7fce4c1000,0xfffffd7fce5c1000],  sp=0xfffffd7fce5c0540,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xee9ea7]  bool NMethodIterator::next_nmethod()+0x547;;  __1cPNMethodIteratorMnext_nmethod6M_b_+0x547
V  [libjvm.so+0x1b2df95]  void NMethodSweeper::sweep_code_cache()+0x4b5;;  __1cONMethodSweeperQsweep_code_cache6F_v_+0x4b5
V  [libjvm.so+0x1b2d9e8]  void NMethodSweeper::possibly_sweep()+0x148;;  __1cONMethodSweeperOpossibly_sweep6F_v_+0x148
V  [libjvm.so+0x1b2d49c]  void NMethodSweeper::sweeper_loop()+0x39c;;  __1cONMethodSweeperMsweeper_loop6F_v_+0x39c
V  [libjvm.so+0x1b922ff]  void JavaThread::thread_main_inner()+0x1df;;  __1cKJavaThreadRthread_main_inner6M_v_+0x1df
V  [libjvm.so+0x1b91f5d]  void JavaThread::run()+0x3bd;;  __1cKJavaThreadDrun6M_v_+0x3bd
V  [libjvm.so+0x18fe53d]  java_start+0x10d;;  java_start+0x10d
C  [libc.so.1+0xdd60b]  _thr_setup+0x5b;;  _thr_setup+0x5b
C  [libc.so.1+0xdd840]  _lwp_start+0x0;;  _lwp_start+0x0

CodeCache: size=49152Kb used=32832Kb max_used=32832Kb free=16320Kb
 bounds [0xfffffd7ff9400000, 0xfffffd7ffb420000, 0xfffffd7ffc400000]
 total_blobs=610 nmethods=44 adapters=443
 compilation: enabled
Comments
The test allocates CodeBlobs in the code cache by using the Whitebox API method 'WhiteBox::allocate_code_blob' introduced by JDK-8059624. The VM crashes while sweeping because it encounters an allocated but uninitialized CodeBlob in the code cache (crash happens in NMethodIterator::next_method because we call '_code_blob->is_nmethod()' on an uninitialised CodeBlob). The problem is that 'WhiteBox::allocate_code_blob' gives up the CodeCache_lock before initializing the CodeBlob. This allows the sweeper thread to encounter a yet uninitialized CodeBlob while iterating over the code cache.
25-11-2014