United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6956931 assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint
JDK-6956931 : assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

Details
Type:
Bug
Submit Date:
2010-05-28
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
generic
Sub-Component:
jvmti
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs19
Fixed Versions:
hs19 (b03)

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

Sub Tasks

Description
JvmtiExport::post_compiled_method_unload_at_safepoint() is failing in
the following way:

    Internal Error (src/share/vm/prims/jvmtiExport.cpp:1868), pid=22577, tid=14
    assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

Here is the code for the failure point:

   1866 // used at a safepoint to post a CompiledMethodUnload event
   1867 void JvmtiExport::post_compiled_method_unload_at_safepoint(jmethodID mid,
 const void *code_begin) {
   1868   assert(SafepointSynchronize::is_at_safepoint(), "must be executed at a safepoint");
   1869 
   1870   // create list lazily
   1871   if (_pending_compiled_method_unload_method_ids == NULL) {

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

    nsk/jvmti/CompiledMethodUnload/compmethunload001
    nsk/jvmti/RedefineClasses/redefclass028
    nsk/jvmti/RedefineClasses/redefclass029
    nsk/jvmti/RedefineClasses/redefclass030
    nsk/jvmti/scenarios/capability/CM02/cm02t001
    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM05/em05t001
    nsk/jvmti/scenarios/events/EM05/em05t002
    nsk/jvmti/scenarios/events/EM07/em07t002
    nsk/jvmti/scenarios/multienv/MA10/ma10t006

These failures have been see on Solaris SPARC, Solaris SPARC-V9 and
Solaris AMD64 configs. Not all of the tests fail in every config in
evey run.

Here is a link to the Solaris SPARC Client VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparc/client/comp/solaris-sparc_client_comp_nsk.jvmti.testlist/analysis.html


Here is a link Solaris SPARC-V9 Server VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparcv9/server/comp/solaris-sparcv9_server_comp_nsk.jvmti.testlist/analysis.html


Here is a link to the Solaris AMD64 Server VM -Xcomp failures:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-amd64/server/comp/solaris-amd64_server_comp_nsk.jvmti.testlist/analysis.html
Here is a stack trace snippet from the hs_err file from one of the failures:

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

Current thread (0x00000001007b7000):  JavaThread "CompilerThread1" daemon [_thread_in_vm, id=14, stack(0xffffffff60600000,0xffffffff60700000)]

Stack: [0xffffffff60600000,0xffffffff60700000],  sp=0xffffffff606ff0f0,  free space=3fcffffffff7e4cfa40k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xeb10dc];;  __1cHVMErrorOreport_and_die6M_v_+0x6bc
V  [libjvm.so+0x504280];;  __1cPreport_vm_error6Fpkci11_v_+0x78
V  [libjvm.so+0x983194];;  __1cLJvmtiExportbOpost_compiled_method_unload_at_safepoint6FpnK_jmethodID_pkv_v_+0x64
V  [libjvm.so+0xb6c450];;  __1cHnmethodbAmake_not_entrant_or_zombie6MI_b_+0x690
V  [libjvm.so+0xd8ab54];;  __1cONMethodSweeperQsweep_code_cache6F_v_+0x5b4
V  [libjvm.so+0xd8a578];;  __1cONMethodSweeperOpossibly_sweep6F_v_+0x90
V  [libjvm.so+0x467b28];;  __1cMCompileQdDueueDget6M_pnLCompileTask__+0x20
V  [libjvm.so+0x46bb38];;  __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x270
V  [libjvm.so+0xe033fc];;  __1cKJavaThreadRthread_main_inner6M_v_+0x174
V  [libjvm.so+0xe03268];;  __1cKJavaThreadDrun6M_v_+0x310
V  [libjvm.so+0xbc8f2c];;  java_start+0x184

The other stacks appear to be similar.
These failures have also been observed on Linux-AMD64, Win32 and
Win-AMD64. Changed the call record OS to be "generic". Also changed
the build to HSX-19-B01 show that failures will show up as "known".
The sub-baselines have the code the introduced the failures, but
the hotspot_version bump to HSX-19-B02 hasn't trickled down yet.

                                    

Comments
PUBLIC COMMENTS

The recent nmethod sweeper changes in 6950075 took the nmethod cleanup out of the safepoint-only path. The assert may no longer be valid - or it may be that the jvmti code is no longer being safely called!
                                     
2010-05-29
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/852d0157c696
                                     
2010-06-02
EVALUATION

6956931: assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint
Reviewed-by: kvn, dcubed

Since the sweeper no longer runs at a safepoint the compiled method
unload logic doesn't always run at a safepoint so we need a new
synchronous notification path that's equivalent to the
compiled_method_load logic.  I refactored the code a bit to share the
core notification logic and I refactored the notification in nmethod
to remove duplication.  Tested with NSK jvmti,jdb,jdi,hprof suites.

src/share/vm/code/nmethod.cpp
src/share/vm/prims/jvmtiExport.hpp
src/share/vm/prims/jvmtiExport.cpp
                                     
2010-06-03



Hardware and Software, Engineered to Work Together