Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6453355

new No_Safepoint_Verifier uses fail during GC

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • hs12
    • 6, 7
    • hotspot
    • b02
    • generic
    • generic
    • Not verified

        # 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.

              sspitsyn Serguei Spitsyn
              rfield Robert Field (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: