On Merlin b53 + Karen's suspend/resume fixes, on Solaris/Intel (probably
irrelevant) running jvmg1 volano w/SafepointALot and cpu=samples,
the client got a sig 11 due to the following stack:
Klass::size_helper(this=0x8)
oopDesc::size(this=0xd95120e8)
jvmpi::request_event(event_type=4, arg=0xd95120e8)
hprof_fetch_object_info(0xd95120e8)
hprof_lookup_class(0xd95120e8)
hprof_class_unload_event(0x845a378, 0xd95120e8)
jvmpi::post_event_vm_mode(event=0xdf13ab8, calling_thread=0x84)
jvmpi::post_class_load_events()
GenCollectedHeap::do_colletion(this=0x80cfd60, full=0, clear_at_refs=0,
size=0, large_no_ref=0, tlab=0, max+level=?, notify_ref=1)
GenCollectedHeap::satisfy_failed_allocation
...
a print of 0xd95120e8 reveals:
oopDesc::_mark/0xd9427ea8
_klass/nil
My interpretation of this is that:
During the GC processing, any class_unload_events are stored
away in a saved unloaded_classes, and at the end of GenCollectedHeap,
we ask to post_class_unload_events, which walks through this
set of stored oopDescs and posts them one by one.
What appears to have happened here, is that the GC moved this
oopDesc, and the _mark field contains the forwarding location.
I don't know how to ensure that the unloaded_classes entries
are listed as GC roots, so that they too get updated during
GC. This is tricky since these are generated part-way through
the GC processing itself.
- relates to
-
JDK-4454725 RequestEvent shall check the input argument before dereferencing it as an oop
-
- Closed
-
-
JDK-4414956 Hotspot crashes running DrawIMGPerf with hprof on Solaris
-
- Closed
-