United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6453355 new No_Safepoint_Verifier uses fail during GC
JDK-6453355 : new No_Safepoint_Verifier uses fail during GC

Details
Type:
Bug
Submit Date:
2006-07-27
Status:
Closed
Updated Date:
2012-10-01
Project Name:
JDK
Resolved Date:
2011-04-20
Component:
hotspot
OS:
generic
Sub-Component:
jvmti
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:
hs12 (b02)

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

Sub Tasks

Description
# Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

    Current thread (0x0a8b1800):  JavaThread "Thread-2" [_thread_in_vm, id=22323]

    Stack: [0xed57c000,0xed5cd000),  sp=0xed5cc080,  free space=320k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V  [libjvm.so+0x72ea48];;  _ZN7VMError14report_and_dieEv+0x258
    V  [libjvm.so+0x37b735];;  _Z24report_assertion_failurePKciS0_+0x55
    V  [libjvm.so+0x3ad013];;  _ZN14No_GC_VerifierC2Eb+0x43
    V  [libjvm.so+0x5b2f59];;  _ZN16JvmtiThreadStateD1Ev+0xd9
    V  [libjvm.so+0x57c837];;  _ZN27JvmtiEventControllerPrivate12thread_endedEP10JavaThread+0xf7
    V  [libjvm.so+0x6e5afa];;  _ZN10JavaThreadD0Ev+0x11a
    V  [libjvm.so+0x6e5de5];;  _ZN10JavaThread17thread_main_innerEv+0x95
    V  [libjvm.so+0x6247a2];;  _Z10java_startP6Thread+0x122
    C  [libpthread.so.0+0x53ae]

Seen in JDI instancecounts004 stress testing on fastdebug on opteron.

The verify no GC flag should be false for this and related No_Safepoint_Verifier uses.
This assertion also popped up in the 2006.08.09 nightly. Here is the analysis entry:

New nsk.jvmti failures (from 2006.08.09)
    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM07/em07t002
        These tests failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 72)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Solaris X86 Client VM (machine cyborrea), Solaris SPARC
        Client VM (machine jtg-s130), Solaris X86 Server VM (machine
        maneesha), Linux IA32 Server VM (machine alcyone), Solaris
        AMD64 Server VM (machine vm-v20z-8), and Linux AMD64 Server VM
        (machine opteron003)

        These tests are covered by the following test bug:

            5055417 4/5 TEST: warnings and notes caused by generification

        This bug is in state incomplete and is on the old exclude list.
        This test was not run on 2006.08.08 so I'm guessing that these
        tests came off the new exclude list for the 2006.08.09 run.

        These tests should be added to the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC
This assertion also popped up in the 2006.10.25 nightly. Here is the analysis entry:

New nsk.quick_jdi failures (from 2006.10.25)
    nsk/jdi/ObjectReference/referringObjects/referringObjects003
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 72)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Linux IA32 Server VM (machine peas). This is an occurrence
        of the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.
This assertion also popped up in the 2006.10.31 nightly. Here is the analysis entry:

New nsk.quick_jdi failures (from 2006.10.31)
    nsk/jdi/MonitorContendedEnteredRequest/addClassExclusionFilter
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 72)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Linux AMD64 Server VM (machine john). This is an occurrence
        of the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.
Test 
	nsk/jdi/ObjectReference/referringObjects/referringObjects002
fails with fastdebug build with same assertion.
This assertion also popped up in the 2007.02.14 nightly. Here is the analysis entry:

New nsk.quick_jdi failures (from 2007.02.14)
    nsk/jdi/VirtualMachine/instanceCounts/instancecounts003
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 72)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Linux IA32 Server VM (machine dip). This failure mode is
        covered by the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.
New failure in c2_baseline

nsk/jdi/MonitorContendedEnterRequest/addInstanceFilter

Tom R. wrote:

2007-02-17/C2_Baseline/vm/64BITLINUX-AMD64/server/comp/vm-vm_6.0_server_comp_64BITLINUX-AMD642007-02-17-20-07-54/hs_err_pid23490.log

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/PrtBuildDir/workspace/src/share/vm/memory/gcLocker.cpp, 72), pid=23490, tid=1090754912
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20070215074942.sgoldman.6523546-1-fastdebug compiled mode)
#
# Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Here's the decoded call stack from the crash:

Stack: [0x0000000040f39000,0x000000004103a000),  sp=0x0000000041038da0,  free space=1023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9e036a];;  _ZN7VMError14report_and_dieEv+0x24a
V  [libjvm.so+0x3c522e];;  _Z24report_assertion_failurePKciS0_+0x6e
V  [libjvm.so+0x4331a8];;  _ZN14No_GC_VerifierC2Eb+0x68
V  [libjvm.so+0x6e4715];;  _ZN16JvmtiThreadStateD1Ev+0x125
V  [libjvm.so+0x6a58e9];; _ZN27JvmtiEventControllerPrivate12thread_endedEP10JavaThread+0x129
V  [libjvm.so+0x6a75e9];;  _ZN20JvmtiEventController12thread_endedEP10JavaThread+0x9
V  [libjvm.so+0x6ba09e];;  _ZN11JvmtiExport14cleanup_threadEP10JavaThread+0x7e
V  [libjvm.so+0x97f52f];;  _ZN10JavaThreadD0Ev+0x12f
V  [libjvm.so+0x97f81e];;  _ZN10JavaThread17thread_main_innerEv+0x9e
V  [libjvm.so+0x97f70d];;  _ZN10JavaThread3runEv+0x11d
V  [libjvm.so+0x7ef9e4];;  _Z10java_startP6Thread+0x154

The full log is at /net/gtee/export/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-02-17/C2_Baseline/vm/64BITLINUX-AMD64/server/comp/vm-vm_6.0_server_comp_64BITLINUX-AMD642007-02-17-20-07-54/hs_err_pid23490.log

One interesting thing is that the current thread isn't in the thread list and looking at the code confirms that at the point we're asserting the JavaThread is most of the way done with exiting and has been removed from the thread list, so it's not safe to use a No_GC_Verifier since it's no longer participating in safepoints.  Here's the code in question in ~JvmtiThreadState:

  // remove us from the list
  {
    // The thread state list manipulation code must not have safepoints.
    // See periodic_clean_up().
    debug_only(No_Safepoint_Verifier nosafepoint;)

    if (_prev == NULL) {
      assert(_head == this, "sanity check");
      _head = _next;
    } else {
      assert(_head != this, "sanity check");
      _prev->_next = _next;
    }
    if (_next != NULL) {
      _next->_prev = _prev;
    }
    _next = NULL;
    _prev = NULL;
  }

The No_Safepoint_Verifier is unsafe and unnecessary.

It also seems wrong to me that a Thread which has been removed from the thread list is still in the state thread_in_vm.
This assertion also popped up in the 2007.08.08 nightly.
Here is the analysis entry:

New nsk.quick_jdi (from 2007.08.08)
*   nsk/jdi/stress/serial/mixed002
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 89)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Linux IA32 Client VM (machine jtg-linux17). This failure
        mode is covered by the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.
This assertion also popped up in the 2007.08.31 nightly.
Here is the analysis entry:

New nsk.jvmti (from 2007.08.31)
*   nsk/jvmti/AttachOnDemand/attach028
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 89)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Solaris AMD64 Server VM (machine vm-v20z-14). This failure
        mode is covered by the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.
This assertion also popped up in the 2007.09.03 nightly.
Here is the analysis entry:

New nsk.jvmti (from 2007.09.03)
*   nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn002
        This test failed the following assertion:

            Internal Error (src/share/vm/memory/gcLocker.cpp, 89)
            Error: assert(!h->is_gc_active(),"GC active during No_GC_Verifier")

        on Solaris SPARC Server VM (machine vm-v215-01). This failure
        mode is covered by the following bug:

            6453355 4/4 new No_Safepoint_Verifier uses fail with parallel GC

        I will add this test to 6453355.

                                    

Comments
EVALUATION

Not an issue for the product but interfers with fastdebug testing
                                     
2006-07-27
SUGGESTED FIX

Please, see the suggested fix in the attachment hs_spv.Nov7.tar.gz .
                                     
2008-01-25



Hardware and Software, Engineered to Work Together