JDK-4974024 : deadlock at VM startup when JVMPI / JDWP both enabled
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9,windows_xp
  • CPU: x86,sparc
  • Submitted: 2004-01-06
  • Updated: 2004-09-29
  • Resolved: 2004-07-20
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.
Other JDK 6
1.4.2_10Fixed 6 mustangFixed
Related Reports
Relates :  
Description

Name: tb29552			Date: 01/05/2004


FULL PRODUCT VERSION :
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows NT 5.01

A DESCRIPTION OF THE PROBLEM :
JVM never completes startup when JVMPI is enabled and it is being debugged.

If I was a betting man, I'd say there was some kind of deadlock occurring, because it just hangs, shortly after JVM_OnLoad.

This is a regression, 1.4.2_01 and early works fine.

FYI, problem also occurs with 1.5.0-b26

You wouldn't think it would be much of a problem, but I need to collect coverage data while debugging my program & that requires JVMPI.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This occurs ONLY on 1.4.2_02, 1.4.2_01 and 1.4.2_00 work fine.

Steps:

[f:\jdks\jdk1.4.2\demo\jfc\notepad]  jdb
Initializing jdb ...
> run -Xrunhprof -jar Notepad.jar
run  -Xrunhprof -jar Notepad.jar

[ VM hangs at this point ]



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When it works (for 1.4.2_01, for example), the notepad window opens. :)
ACTUAL -
JVM hangs at 0% CPU until control-c is pressed.

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 229515) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang tiger-rc FIXED IN: mustang tiger-rc INTEGRATED IN: mustang tiger-rc
30-09-2004

EVALUATION ###@###.### 2004-01-09 Does not happon with 1.5 beta1. ###@###.### 2004-07-02 This no longer happens with 1.5 and hprof because hprof no longer uses JVMPI. However, jcov does use JVMPI and this happens with jcov. To see this bug occur, do this: cd /net/jano.sfbay/export/disk20/serviceability/ws/regressionTestsInWaiting/JVMPIDeadlock ./jj1.sh When this passes, you get an error msg: ERROR: transport error 202: connect failed: Connection refused ["transport.c",L41] When it fails, the VM hangs before it can print the error msg. It fails intermittently, so if at first you don't fail, try, try again. Also, see file jj.txt in the above dir for stack traces and analysis. See also bug 4852569: OBJ_ALLOC event deadlock between VMThread and Finalizer thread It looks like this might be another instance of that bug more or less. Name: dd4877 Date: 07/14/2004 daniel.daugherty@Sun 2004-07-14 This bug is not a variant of 4852569. However, it was caused by the fix for 4852569. JVM/PI JVM_INIT_DONE event processing and the related event posting restrictions need to be done before JVM/DI/TI VM_INIT event processing. ======================================================================
30-09-2004

SUGGESTED FIX Name: dd4877 Date: 07/14/2004 daniel.daugherty@Sun 2004-07-14 Here are the context diffs for the suggested fix: ------- src/share/vm/runtime/thread.cpp ------- *** /tmp/sccs.OtaiWb Wed Jul 14 14:36:54 2004 --- thread.cpp Wed Jul 14 14:22:24 2004 *************** *** 2883,2895 **** create_vm_init_libraries(); } - // Notify JVMTI agents that VM initialization is complete - nop if no agents. - JvmtiExport::post_vm_initialized(); - // Issue class load, thread start and object allocation events for all // preloaded classes if there is an interested agent. Also, lift the // event posting restriction whether there is an agent attached now or // not; an agent may attach later when no restrictions apply. jvmpi::post_vm_initialization_events(); if (jvmpi::is_event_enabled(JVMPI_EVENT_JVM_INIT_DONE)) { --- 2883,2898 ---- create_vm_init_libraries(); } // Issue class load, thread start and object allocation events for all // preloaded classes if there is an interested agent. Also, lift the // event posting restriction whether there is an agent attached now or // not; an agent may attach later when no restrictions apply. + // + // The JVM/PI event posting restriction can cause deadlock if there + // is also a JVM/DI or JVM/TI agent attached and the agent's VM_INIT + // event handler causes a JVM/PI event to be posted. To prevent the + // deadlock risk, JvmtiExport::post_vm_initialized() must be called + // after the JVM/PI event posting restriction is lifted. jvmpi::post_vm_initialization_events(); if (jvmpi::is_event_enabled(JVMPI_EVENT_JVM_INIT_DONE)) { *************** *** 2898,2903 **** --- 2901,2909 ---- jvmpi::post_vm_initialized_event(); } + // Notify JVMTI agents that VM initialization is complete - nop if no agents. + JvmtiExport::post_vm_initialized(); + Chunk::start_chunk_pool_cleaner_task(); #ifndef CORE RecompilationMonitor::start_recompilation_monitor_task(); ======================================================================
30-09-2004

PUBLIC COMMENTS .
30-09-2004