JDK-6956931 : assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs19
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-05-28
  • Updated: 2012-02-01
  • Resolved: 2011-03-07
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 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
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
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
03-06-2010

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

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!
29-05-2010