Bug ID: JDK-6897143 Stress test crashes during HeapInspection using ParallelGC.

JDK-6897143 : Stress test crashes during HeapInspection using ParallelGC.

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: hs17,5.0u22,6u13

Priority: P3
Status: Resolved
Resolution: Fixed
OS: generic,solaris,solaris_10
CPU: generic,x86,sparc

Submitted: 2009-11-02
Updated: 2011-04-22
Resolved: 2010-05-04

Versions (Unresolved/Resolved/Fixed)

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.

Other	Other	Other	JDK 6	JDK 7	Other
5.0u23-rev,hs16.3Fixed	5.0u24-revFixed	5.0u25Fixed	6u20-rev b05Fixed	7Fixed	hs16.3Fixed

Related Reports

Duplicate :	JDK-6861302 - JVM crashed while dumping heap - JRE 1.6.0_13
Duplicate :	JDK-6940126 - Bigapp fails with SIGSEGV in native code
Relates :	JDK-6450362 - Crash in heap inspection using jmap -histo
Relates :	JDK-6621728 - Heap inspection should not crash in the face of C-heap exhaustion
Relates :	JDK-2201636 - JVM crash at KlassInfoTable::record_instance
Relates :	JDK-6944195 - jmap -{histo,dump}:live, +PrintClassHistogram and friends should stall for GC locker to clear
Relates :	JDK-6850053 - JVM crash at KlassInfoTable::record_instance

Description

Customer stress test crashes during heap inspection using PrintClassHistogram.

Crashes while testing 6.0_17-b02 and 1.5.0_22-b02.

Crashing in -Xint mode.

Unable to reproduce with CMS GC or with serial collector.

-XX:+VerifyBeforeGC, -XX:+VerifyDuringGC, and -XX:+VerifyAfterGC do not report a problem.

Example stack: pstack19441_xint.out

-----------------  lwp# 18 / thread# 18  --------------------
...snip...
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fe8ba6e4 bool KlassInfoTable::record_instance(oopDesc*const) (6c1ff8dc, dd80bf70, 6f8b60, e0237118, 0, dd80bf70) + 30
 fe8bb154 void RecordInstanceClosure::do_object(oopDesc*) (6c1ff8cc, dd80bf70, c00c0501, 6d400448, 48, 49) + 8
 fe65d16c void MutableSpace::object_iterate(ObjectClosure*) (33d08, 6c1ff8cc, 48, e0237118, fede4ed4, dd80bf70) + 24
 feb31fd4 void PSYoungGen::object_iterate(ObjectClosure*) (34540, 6c1ff8cc, 34408, d6a918, fe65d148, fedeb5c8) + 10
 feb0ab84 void ParallelScavengeHeap::object_iterate(ObjectClosure*) (feded800, 6c1ff8cc, 4e2b, feb0ab70, fededa18, feded800)
+ 14
 fe8baed8 void HeapInspection::heap_inspection(outputStream*) (2cfa0, 4e2b, 34408, d6a918, 0, fecbdde4) + 1fc
 fec0932c void VM_GC_HeapInspection::doit() (6beffc80, 4bc, 7f7b2f, fedec490, fee, 7f74c1) + 9c
 fe5d8088 void VM_Operation::evaluate() (6beffc80, 2de08, fedb2000, fee, 7f74c1, 3a400) + 80
 fec0bc30 void VMThread::evaluate_operation(VM_Operation*) (2de08, 6beffc80, 1c2750, 7f74c1, 1c2758, fedb2000) + cc
 fec0c1c8 void VMThread::loop() (0, 3d1a0, 2f708, 1, fee02dd0, 4a968) + 45c
 fe65a92c void VMThread::run() (1c2400, 39400, fedeb74c, fedb2000, 3974c, 39400) + 98
 feaf5910 java_start (1c2400, 4bf1, fedb2000, fed00079, 1c36d0, fedfb3f4) + 22c
 ff2c6d4c _lwp_start (0, 0, 0, 0, 0, 0)

Comments

EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/7cbd1e7b56ba
22-04-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bdb5361c461c
19-04-2010
SUGGESTED FIX JDK6: (5.10)$ hg diff src/share/vm/gc_implementation/shared/vmGCOperations.cpp diff -r b9408ac1b596 src/share/vm/gc_implementation/shared/vmGCOperations.cpp --- a/src/share/vm/gc_implementation/shared/vmGCOperations.cpp Thu Feb 11 20:27:54 2010 -0800 +++ b/src/share/vm/gc_implementation/shared/vmGCOperations.cpp Mon Apr 12 23:40:16 2010 +0100 @@ -115,11 +115,10 @@ void VM_GC_HeapInspection::doit() { void VM_GC_HeapInspection::doit() { HandleMark hm; CollectedHeap* ch = Universe::heap(); + ch->ensure_parsability(false); // must happen, even if collection does + // not happen (e.g. due to GC_locker) if (_full_gc) { ch->collect_as_vm_thread(GCCause::_heap_inspection); - } else { - // make the heap parsable (no need to retire TLABs) - ch->ensure_parsability(false); } HeapInspection::heap_inspection(_out, _need_prologue /* need_prologue */); }
15-04-2010
EVALUATION The JDK 6 crash was harder to reproduce but the testsuite "bigapps/JBoss+Todo" is now triggering it reliably. In e.g. hotspot 16 and 17, there is an ensure_parsability() call, but the GC_locker being active will mean we return from the PSMarkSweep::invoke_no_policy before it is made. Reworking VM_GC_HeapInspection::doit() to always call ensure_parsability() appears to be a clear and correct fix.
15-04-2010
EVALUATION Believe this evaluation only holds for the 5.0 crash. Hoping to get more info from a 6.0 crash and a jdk7b77 crash just reported...
14-12-2009
EVALUATION During HeapInspection::heap_inspection, there is no call to ensure_parsability() before doing the heap walk... (which does happen before a real GC with the parallel collector).
24-11-2009