JDK-6608862 : segv in JvmtiEnvBase::check_for_periodic_clean_up()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs11,hs12
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2007-09-25
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
Description
Compiler nightly tests saw a failure running regression test HeapwalkingTest.java with the option -XX:CompileThreshold=100. 

I was able to reproduce this on the nightly testing machine em64t-002.SFBay (a 4cpu xeon) although it was fairly difficult. Only 1 out of 20-30 runs would fail. It appears to fail after the test runs for quite a bit (this is significant given the failure). After finally getting a core file here is what I observed. The vmthread crashes with this stack trace:

#0  0x00000037b922e37d in raise () from /lib64/tls/libc.so.6
#1  0x00000037b922faae in abort () from /lib64/tls/libc.so.6
#2  0x0000002a95e5fd5e in os::abort () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#3  0x0000002a9603b675 in VMError::report_and_die () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#4  0x0000002a95e66e00 in JVM_handle_linux_signal () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#5  0x0000002a95e6238a in signalHandler () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#6  <signal handler called>
#7  0x0000002a95d0a670 in JvmtiEnvBase::check_for_periodic_clean_up()::ThreadInsideIterationClosure::do_thread ()
#9  0x0000002a95d054fc in JvmtiEnvBase::check_for_periodic_clean_up () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#10 0x0000002a95d23912 in JvmtiGCMarker::JvmtiGCMarker$base () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#11 0x0000002a9603cc82 in VM_ParallelGCFailedAllocation::doit () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#12 0x0000002a96075e57 in VM_Operation::evaluate () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#13 0x0000002a96074dc6 in VMThread::evaluate_operation () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#14 0x0000002a96075238 in VMThread::loop () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#15 0x0000002a96074a23 in VMThread::run () from /tmp/jdk/jre/lib/amd64/server/libjvm.so
#16 0x0000002a95e655dd in java_start () from /tmp/jdk/jre/lib/amd64/server/libjvm.so

The reason for the SEGV is that the thread that has been passed to JvmtiEnvBase::check_for_periodic_clean_up()::ThreadInsideIterationClosure::do_thread 
is NULL. The reason the value is NULL is because the value of WatcherThread::_watcher_thread is NULL. I don't know what happened to the watcher thread.

I've attached a snapshot of the stacks for the threads that are active, there is no watcher thread. I'm not sure if this is a runtime problem or a jvmti problem. I flipped a coin and picked runtime. Until they happen to reboot the machine I reproduced this on the core file will be available for further examination. Let me (SteveG) know if you want to find it.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3529d0e8d09c
16-08-2008

EVALUATION We should fix this in JDK 7 as described in comments.
19-10-2007