JDK-7024970 : assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueue
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs21,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2011-03-06
  • Updated: 2011-04-25
  • Resolved: 2011-04-25
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 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
JDK-7026336 - assert(ServiceThread::is_service_thread(Thread::current())) failed
Relates :  
JDK-6766644 - Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"
Description
Observed the following assertion failure in the 2011.03.03
RT_Baseline nightly:

#  Internal Error (/tmp/jprt/P2/B/154445.bd148109/source/src/share/vm/prims/jvmtiImpl.cpp:944), pid=14980, tid=2693274512
#  assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueued events
#
# JRE version: 7.0-b131
# Java VM: Java HotSpot(TM) Server VM (21.0-b03-internal-201103031544.bd148109.hotspot-fastdebug compiled mode linux-x86 )
# Core dump written. Default location: /export/local/43630.JDK7.NIGHTLY.VM+linux-i586_vm_server_comp_nsk.jvmti.testlist/results/ResultDir/compmethunload001/core or core.14980
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x08291000):  JavaThread "Service Thread" daemon [_thread_in_vm, id=14993, stack(0xa0831000,0xa0882000)]

Stack: [0xa0831000,0xa0882000],  sp=0xa0880e20,  free space=319k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa80251]  VMError::report_and_die()+0x1a1;;  VMError::report_and_die()+0x1a1
V  [libjvm.so+0x4bd1f8]  report_vm_error(char const*, int, char const*, char const*)+0x68;;  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0x767587]  JvmtiDeferredEvent::post()+0xb7;;  JvmtiDeferredEvent::post()+0xb7
V  [libjvm.so+0x977014]  ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x2c4;;  ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x2c4
V  [libjvm.so+0xa290b4]  JavaThread::thread_main_inner()+0xf4;;  JavaThread::thread_main_inner()+0xf4
V  [libjvm.so+0x8b3991]  java_start(Thread*)+0x111;;  java_start(Thread*)+0x111
C  [libpthread.so.0+0x61b5]  start_thread+0xc5


This assertion failure was seen in the following VM/NSK tests:

    nsk/jvmti/CompiledMethodUnload/compmethunload001
    nsk/jvmti/RedefineClasses/redefclass028
    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM07/em07t002
    nsk/jvmti/scenarios/hotswap/HS101/hs101t001
    nsk/jvmti/scenarios/multienv/MA10/ma10t006
A few tests showed up in the 2011.03.04 RT_Baseline nightly:

    nsk/jvmti/RedefineClasses/redefclass029
    nsk/jvmti/RedefineClasses/redefclass030
    nsk/jvmti/scenarios/capability/CM02/cm02t001
    nsk/jvmti/scenarios/hotswap/HS101/hs101t002
    nsk/jvmti/scenarios/hotswap/HS101/hs101t003
    nsk/jvmti/scenarios/hotswap/HS101/hs101t004
    nsk/jvmti/scenarios/hotswap/HS101/hs101t006
    nsk/jvmti/scenarios/hotswap/HS102/hs102t001
Another test showed up in the 2011.03.08 RT_Baseline nightly:

    nsk/jvmti/scenarios/multienv/MA10/ma10t006
Another test showed up in the 2011.03.09 RT_Baseline nightly:

    nsk/jvmti/scenarios/hotswap/HS102/hs102t002
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/46a56fac55c7
17-03-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/46a56fac55c7
16-03-2011
SUGGESTED FIX Here's the context diff for this one line fix: $ hg diff src/share/vm/runtime/serviceThread.cpp diff -r 4f148718983e src/share/vm/runtime/serviceThread.cpp --- a/src/share/vm/runtime/serviceThread.cpp Thu Mar 10 17:44:32 2011 +0100 +++ b/src/share/vm/runtime/serviceThread.cpp Mon Mar 14 09:52:45 2011 -0700 @@ -70,11 +70,10 @@ void ServiceThread::initialize() { java_lang_Thread::set_priority(thread_oop(), NearMaxPriority); java_lang_Thread::set_daemon(thread_oop()); thread->set_threadObj(thread_oop()); + _instance = thread; Threads::add(thread); Thread::start(thread); - - _instance = thread; } } This fix was also included in the webrevs for 7024234.
14-03-2011
EVALUATION Here is the code that is asserting: src/share/vm/prims/jvmtiImpl.cpp: 943 void JvmtiDeferredEvent::post() { 944 assert(ServiceThread::is_service_thread(Thread::current()), 945 "Service thread must post enqueued events"); 946 switch(_type) { Here is the is_service_thread() query code: src/share/vm/runtime/serviceThread.cpp: 120 bool ServiceThread::is_service_thread(Thread* thread) { 121 return thread == _instance; 122 } The thread parameter is compared to the _instance field. However, there is a race between the assertion in the event posting code and in the ServiceThread launching code: src/share/vm/runtime/serviceThread.cpp: 72 thread->set_threadObj(thread_oop()); 73 74 Threads::add(thread); 75 Thread::start(thread); 76 77 _instance = thread; 78 } 79 } The thread is started on line 75, but the _instance field is not set until line 77. That gives the ServiceThread a chance to get to the assertion before the launching thread can set the _instance field. Moving the initialization of the _instance field before the ServiceThread is started will solve the race.
06-03-2011