JDK-8038925 : Java with G1 crashes in dump_instance_fields using jmap or jcmd without fullgc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7u51
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-04-01
  • Updated: 2018-03-20
  • Resolved: 2014-05-28
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 7 JDK 9
7u72Fixed 9Resolved
Related Reports
Duplicate :  
JDK-8035951 - Crash in build 1.7.0_40-b43 when using g1 and heapdumpbeforefullgc.
Relates :  
JDK-8043538 - assert(o->is_oop_or_null()) failed: should always be an oop, at heapDumper.cpp:724
Description
G1CollectedHeap::safe_object_iterate uses ContiguousSpace::object_iterate_from which does not avoid dead objects that can still be on the heap when using G1 and no fullgc has happened.

[VM_Operation (0x00007f6dcfd3ae00): G1IncCollectionPause, mode: safepoint, requested by thread 0x00007f6dc800b800]
[VM_Operation (0x00007f6dcfd3b620): G1IncCollectionPause, mode: safepoint, requested by thread 0x00007f6dc800b800]
[VM_Operation (0x00007f6dc4b8ec00): CGC_Operation, mode: safepoint, requested by thread 0x00007f6dc803e800]
[VM_Operation (0x00007f6dc4b8ec00): CGC_Operation, mode: safepoint, requested by thread 0x00007f6dc803e800]
[VM_Operation (0x00007f6dcfd3ae50): G1IncCollectionPause, mode: safepoint, requested by thread 0x00007f6dc800b800]
[VM_Operation (0x00007f6dcfd3b650): G1IncCollectionPause, mode: safepoint, requested by thread 0x00007f6dc800b800]
[VM_Operation (0x00007f6dc4b8ec00): CGC_Operation, mode: safepoint, requested by thread 0x00007f6dc803e800]
[VM_Operation (0x00007f6dc4b8ec00): CGC_Operation, mode: safepoint, requested by thread 0x00007f6dc803e800]
[VM_Operation (0x00007f6dcfd39ae0): HeapDumper, mode: safepoint, requested by thread 0x00007f6dc800b800#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f6dce0f02fc, pid=3437, tid=140108642043648
#
# JRE version: Java(TM) SE Runtime Environment (7.0_65-b06) (build 1.7.0_65-ea-fastdebug-b06)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b01-fastdebug mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x40d2fc]  oopDesc::is_klass() const+0x1c
#
# Core dump written. Default location: /home/aeriksso/cce/bug18490360/core or core.3437
#
# An error report file with more information is saved as:
# /home/aeriksso/cce/bug18490360/hs_err_pid3437.log
Comments
SQE is OK to take this to PSU14_04
09-07-2014
Fix Summary Template - Fix for Release : 7 PSU - Risk Analysis : Low, one line fix - Testing (done/to-be-done) : Automated test included in push
26-06-2014
Setting fixversion to 7 and adding labels 8-na and 9-na. Will open a new bug for the assert that can fail in jdk8/9.
20-05-2014
Suggested fix: Add a dead-object avoiding object_iterate_from method to G1:s HeapRegion class, so that it is used when iterating the heap with G1.
30-04-2014
Can reproduce on jdk9 as well, re-targeting. Some info on why this happens: On 2014-04-30 11:42, Thomas Schatzl wrote: > Hi, > > On Wed, 2014-04-30 at 11:34 +0200, Mikael Gerdin wrote: >> Ok. I had a chat with Andreas now and here's my view on how this crash can >> happen: >> >> Object o1 in region r1 points to humongous object o2 in r2. >> o1 and o2 are not reachable. >> r2 is freed and later re-used for some other purpose. >> (since o2 is not evacuated the reference from o1 is not updated) >> r1 is considered expensive to evacuate and is kept around. >> >> A heap dump is requested, which performs object_iterate on all in-use regions. >> object_iterate provides a callback to the HeapDumper for each object, dead or >> alive. >> >> The HeapDumper iterates over all the fields of the object and at this point >> o1's reference field which used to point to o2 can now point to arbitrary heap >> memory. >> > Okay, the problem can occur due to the marking cleanup reclaiming empty > regions, and having stale references. Understood. > > Thanks. > >> In JDK8+ the perm gen is dead and gone and as is the is_klass check. >> What's left is an assert(o->is_oop_or_null()) which can be triggered by this >> condition but in product builds nothing bad will happen, except that the hprof >> file will have a strange pointer in it. > So there is still a similar problem in 8/9. Can we also file bugs for > them? > > And normal heap verification internally checks whether the object is > live or not and does not iterate over it.
30-04-2014
My suggested fix failed some asserts, working on a new fix.
22-04-2014