United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4974024 : deadlock at VM startup when JVMPI / JDWP both enabled

Details
Type:
Bug
Submit Date:
2004-01-06
Status:
Resolved
Updated Date:
2004-09-29
Project Name:
JDK
Resolved Date:
2004-07-20
Component:
vm-legacy
OS:
solaris_9,windows_xp
Sub-Component:
jvmpi
CPU:
x86,sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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
PUBLIC COMMENTS

.
                                     
2004-09-30
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();



======================================================================
                                     
2004-09-30
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.



======================================================================
                                     
2004-09-30
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang
tiger-rc

FIXED IN:
mustang
tiger-rc

INTEGRATED IN:
mustang
tiger-rc


                                     
2004-09-30



Hardware and Software, Engineered to Work Together