Bug ID: JDK-6996747 SIGSEGV in nmethod::cleanup_inline

Versions (Unresolved/Resolved/Fixed)

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	JDK 8	Other
7Fixed	8Fixed	hs21Fixed

Application gets SIGSEGV with symptoms of 6966246 after 71 hours. JDK 7/b115, HS 20 b02 is used.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfd3d50c2, pid=11667, tid=7

...

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9d50c2];;  void CompiledIC::verify()+0x566
V  [libjvm.so+0x178a01e];;  void nmethod::cleanup_inline_caches()+0x32e
V  [libjvm.so+0x1b3498c];;  void NMethodSweeper::sweep_code_cache()+0x684
V  [libjvm.so+0x1b3426d];;  void NMethodSweeper::possibly_sweep()+0x109
V  [libjvm.so+0x9bcee1];;  CompileTask*CompileQueue::get()+0x1d
V  [libjvm.so+0x9c43f7];;  void CompileBroker::compiler_thread_loop()+0x4db
V  [libjvm.so+0x1c095fa];;  void compiler_thread_entry(JavaThread*,Thread*)+0x2e
V  [libjvm.so+0x1bfb7ed];;  void JavaThread::thread_main_inner()+0x179
V  [libjvm.so+0x1bfb49d];;  void JavaThread::run()+0x619
V  [libjvm.so+0x1823d01];;  java_start+0x711
C  [libc.so.1+0xa7045];;  _thr_setup+0x4e
C  [libc.so.1+0xa7330];;  _lwp_start+0x0

EVALUATION 6996747: SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify Reviewed-by: kvn, iveresov When the sweeper is processing an nmethod it's possible for a safepoint to occur while acquiring locks to clean the inline caches. This can allow the nmethod to be unloaded in the middle of processing it which can result in assertion failures or crashes. I considered modifying the locks to skip the safepoint check but it would require changing CompiledIC_lock, InlineCacheBuffer_lock and VtableStubs_lock which seems risky. Instead I keep track of the currently nmethod in the CompiledThread and scan it when a GC occurs. I also included some sweeper logging code that I wrote while debugging this. Tested with failing test from report though we'll need big apps runs to confirm that there aren't other issues.
17-05-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f52ed367b66d
17-05-2011
EVALUATION I've reproduced this and diagnosed it. The problem is that the code that acquires the CompiledIC_lock can safepoint during the lock acquire. During the safepoint nmethods can become unloaded. If the nmethod we're processing is unloaded then we'll die when we try to clean the caches.
12-05-2011
EVALUATION I have been unable to reproduce after several weeks of trying. Are you able to reproduce this? If so can you point me to a setup where I can do some debugging?
03-05-2011

Duplicate :	JDK-6962697 - Crash in is_call_to_interpreted@CompiledIC / process_nmethod@NMethodSweeper
Duplicate :	JDK-7050273 - CMS: SIGSEGV in SweepClosure::do_blk_careful
Duplicate :	JDK-7035537 - Tiered: assert(check_obj_alignment(result)) failed: address not aligned: 0x0000000000000001
Relates :	JDK-6956958 - assert(is_clean() \|\| is_call_to_compiled() \|\| is_call_to_interpreted() \|\| is_optimized() \|\| is_megam
Relates :	JDK-6966246 - Crash in nmethod::cleanup_inline_caches / CompiledIC::verify