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.
EVALUATION
This problem is seen only on windows-amd64 and it is not easy to reproduce it.
This is random failure.
*** (#1 of 5): 2006-08-22 12:01:19 PDT ###@###.###
I was able to reproduce this after few runs. It is seg faulting in method oop_verify_on(). The faulting thread is vm thread. The def new generation
eden space and from space is almost 100% full. I think it is running
gc. There is no stack trace saved in hs err file to verify this also
I could not get a minidump even after enabling it from drwtsn32 tool.
I suspect this is gc issue.
*** (#2 of 5): 2006-08-23 10:42:06 PDT ###@###.###
It is carshing in jvmtiThreadState::periodic_clean_up() at line marked "<===="
which is trying to deference the env ptr.
while (ets != NULL) {
if (ets->get_env()->is_valid()) { <=====
Which is running in vm thread at safe point.
*** (#3 of 5): 2006-08-25 17:44:38 PDT ###@###.###
We got several failures with similar error messages in spb-nightly in following tests:
nsk/jdi/ObjectReference/referringObjects/referringObjects001
This failures occurs on windows-i586 and it looks like reason of this errors is using of heapwalking methods: VirtualMachine.instanceCounts(), ReferenceType.instances(), ObjectReference.referringObjects() (tests for ThreadReference.ownedMonitorsAndFrames() also use this methods). I created minimized testcase: debuggee vm starts several threads filling memory and debugger calls several times heapwalking methods. This test always crashes on windows machine (this testcase is attached).
*** (#4 of 5): 2006-09-25 05:38:30 PDT ###@###.###
*** Last Edit: 2006-12-29 04:10:23 PST ###@###.###
Problem here is jvmtiEnvBase::periodic_clean_up() is called first which
deletes the jvmtiEnv and then jvmtiThreadState::periodic_clean_up() is
called which tries to access the deleted jvmtiEnv. See jvmtiEnvBase.cpp
file in method check_for_periodic_cleanup() (approx line 232).
*** (#5 of 5): 2007-04-19 12:24:50 PDT ###@###.###