JDK-4325563 : HPROF: CPU sampling can continue during VM shutdown
  • Type: Bug
  • Component: tools
  • Sub-Component: hprof
  • Affected Version: 1.3.0
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2000-03-28
  • Updated: 2004-01-29
  • Resolved: 2004-01-29
Related Reports
Duplicate :  
JDK-4701980 - HPROF: -Xrunhprof option crashes and restarts S1AS app server
Relates :  
JDK-4636055 - HPROF: JVM crashes during Shutdown when cpu=times with many threads, finalizatio
Description
When using the HPROF cpu=samples option it is possible for the VM to shutdown
while the CPU sampling thread continues to take samples. This is because the
JVMPI_EVENT_JVM_SHUT_DOWN event does not cause the sampling thread to
complete.

The sampling thread requires to enter/exit both the data_access_lock and
the hprof_dump_lock. If these monitors are removed during shutdown then
this can potentially cause the sampling thread to crash.
Comments
PUBLIC COMMENTS .
01-09-2004
EVALUATION The new hprof (4473337) is being careful on the timing of termination of the cpu sampling thread, so this should not be an issue. If there was a testcase for this bug report that would have been handy for verification purposes. This bug will probably be closed as "will not fix" once the new hprof (4473337) is integrated into tiger (1.5). ###@###.### 2003-11-09 ###@###.### 2004-01-29 This issue was addressed in a different way in the following bug: 4701980 2/2 HPROF: -Xrunhprof option crashes and restarts S1AS app server The sampler thread should not exit when the hprof_is_on flag is disabled. There is a socket based interface that allows sampling to be enabled and disabled as needed. If the sampler thread exited when hprof_is_on is toggled to off, then sampling could never be resumed. Instead the ability to pause the sampler thread was added and the handler for the JVM_SHUT_DOWN event was modified to use the pause mechanism. Thus the sampler thread pauses on VM shutdown and never runs again. This makes shutdown processing much simpler and more reliable. The webrev is at: http://javaweb.sfbay/~dcubed/4701980-webrev-cr1/ I will close this bug as a duplicate of 4701980 once Alan agrees that I addressed his issues. ###@###.### 2004-01-29 (update 1) Alan concurs that this bug can be closed.
29-01-2004
SUGGESTED FIX The HPROF crashes observed because of this issue arise with a clone VM used by the licensee. As the Classic VM and HotSpot do not tidy up all resources during termination this is probably not easy to duplicate on the reference implementation. An initial fix to this problem is to change the while(1) loop in hprof_cpu.c to be while(hprof_is_on). However this doesn't address the issue completely because there is still a timing window between the shutdown event arriving and the sampling thread exiting. In that window it's possible for the sampling thread to attempt to enter/exit one of the monitors. In addition it's possible that the sampling is disabled and the sampling thread is blocked on hprof_cpu_lock. Therefore the proposed fix is :- 1. In hprof_cpu.c change the loop in hprof_cpu_loop to be while(hprof_is_on). 2. In hprof_cpu.c add the following at the end of the loop :- cpu_sampling = FALSE; /* thread terminates */ 2. In hprof_jvm_shut_down_event (hprof.c) add the following to the end of the function :- /* First wake up the CPU sampler thread */ CALL(RawMonitorEnter)(hprof_cpu_lock); if (cpu_sampling) { CALL(RawMonitorNotifyAll)(hprof_cpu_lock); } /* Now poll every 0.5 second until it exits */ while (cpu_sampling) { CALL(RawMonitorWait)(hprof_cpu_lock, (jlong)500); } CALL(RawMonitorExit)(hprof_cpu_lock); alan.bateman@ireland 2000-03-28
28-03-2000