JDK-8075214 : SIGSEGV in nmethod sweeping
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-16
  • Updated: 2015-08-06
  • Resolved: 2015-03-30
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
9 b64Fixed
Related Reports
Duplicate :  
JDK-8073198 - assert(dmw->is_neutral()) failed: invariant
Relates :  
JDK-8072377 - WhiteBox sweeper thread management bugs
Relates :  
JDK-8072377 - WhiteBox sweeper thread management bugs
Description
NMethod sweeping triggered by WhiteBox crashed:

#  SIGSEGV (0xb) at pc=0xf43c007d, pid=866, tid=3939502960
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150313150524.iignatye.8026047-b00)
# Java VM: Java HotSpot(TM) Client VM (1.9.0-internal-fastdebug-20150313150524.iignatye.8026047-b00 mixed mode linux-x86 )
# Problematic frame:
# j  java.lang.ThreadGroup.add(Ljava/lang/Thread;)V+4

Stack trace:
j  java.lang.ThreadGroup.add(Ljava/lang/Thread;)V+4
v  ~StubRoutines::call_stub
V  [libjvm.so+0x5933f4]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x13e4;;  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x13e4
V  [libjvm.so+0x8aa624]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x24;;  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x24
V  [libjvm.so+0x590c4e]  JavaCalls::call_special(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x32e;;  JavaCalls::call_special(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x32e
V  [libjvm.so+0x591115]  JavaCalls::call_special(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xd5;;  JavaCalls::call_special(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xd5
V  [libjvm.so+0xa1eafa]  JavaThread::allocate_threadObj(Handle, char const*, bool, Thread*)+0x41a;;  JavaThread::allocate_threadObj(Handle, char const*, bool, Thread*)+0x41a
V  [libjvm.so+0xac8259]  WhiteBox::create_sweeper_thread(Thread*)+0x129;;  WhiteBox::create_sweeper_thread(Thread*)+0x129
V  [libjvm.so+0xad340e]  WB_ForceNMethodSweep+0x10e;;  WB_ForceNMethodSweep+0x10e
j  sun.hotspot.WhiteBox.forceNMethodSweep0()Ljava/lang/Thread;+0
j  sun.hotspot.WhiteBox.forceNMethodSweep()V+1
j  AllocationCodeBlobTest$$Lambda$8.run()V+4
j  com.oracle.java.testlibrary.InfiniteLoop.run()V+4


Maybe related to JDK-8072377?
Comments
Evaluation: The test uses the Whitebox API to enforce sweeping by creating and starting a 'CodeCacheSweeperThread'. During creation of the thread, the interpreter crashes in j.l.ThreadGroup.add(Thread t) [1] while executing a subtype check to validate that 't' is a subtype of j.l.Thread [2]. The problem is that we pass 'JavaThread->threadObj()' to 'ThreadGroup.add' which is invalid due to a GC that moved the object. The GC does not know about the thread because it was not yet added to the threads list and therefore does not update the oop. [1] http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/tip/src/java.base/share/classes/java/lang/ThreadGroup.java#l896 [2] see '__ gen_subtype_check' in 'TemplateTable::aastore'
25-03-2015
ILW=Crash in whitebox test (Probable testbug?); once so far; none = M/HLH=P3
17-03-2015