Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
# 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.
|