United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6996747 SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify
JDK-6996747 : SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify

Details
Type:
Bug
Submit Date:
2010-11-02
Status:
Closed
Updated Date:
2011-08-02
Project Name:
JDK
Resolved Date:
2011-07-18
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs19,hs20,hs21
Fixed Versions:
hs21 (b14)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
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?
                                     
2011-05-03
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.
                                     
2011-05-12
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f52ed367b66d
                                     
2011-05-17
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.
                                     
2011-05-17



Hardware and Software, Engineered to Work Together