JDK-4406166 : jdb fails to set breakpoint in HelloWorld
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.1
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-01-19
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
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 Other
1.3.1 rc1Fixed 1.4.0Fixed
Related Reports
Duplicate :  
Relates :  
Description
daniel.daugherty@Eng 2001-01-19

While chasing a different bug, I tried to use jdb with the current
ladybird_baseline and failed miserably. I backtracked the breakage
to the suspend/resume putback on 2001.01.08.

Build 13 - jdb works
20010105 - jdb works
20010108 - jdb fails

Looks like there is a problem with suspend/resume and jdb.

::::::::::::::
HelloWorld.java
::::::::::::::
public class HelloWorld {
    public static void main(String args[]) {
        System.out.println("Hello, world!");
    }
}


user% $JAVA_HOME/bin/java -showversion HelloWorld
java version "1.3.1beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1beta-b13)
Java HotSpot(TM) Client VM (build 1.3.1beta-b13, mixed mode)

Hello, world!

user% $JAVA_HOME/bin/jdb HelloWorld
Initializing jdb...
> stop in HelloWorld.main
Deferring breakpoint HelloWorld.main.
It will be set after the class is loaded.
> run HelloWorld
> 
VM Started: Set deferred breakpoint HelloWorld.main

Breakpoint hit: thread="main", HelloWorld.main(), line=3, bci=0
  3         System.out.println("Hello, world!");

main[1] step
Hello, world!

Step completed: thread="main", HelloWorld.main(), line=4, bci=8
  4     }

main[1] step
The application exited

user% $JAVA_HOME/bin/java -showversion HelloWorld
java version "1.3.1beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1beta-b13)
Java HotSpot(TM) Client VM (build product+1.3.1+ladybird_baseline+compiler1+20010108-100457-release, mixed mode)

# FAIL: the program runs to the end before the breakpoint is set
user% $JAVA_HOME/bin/jdb HelloWorld
Initializing jdb...
> stop in HelloWorld.main
Deferring breakpoint HelloWorld.main.
It will be set after the class is loaded.
> run HelloWorld
Hello, world!
Set deferredbreakpoint HelloWorld.main
> 
VM Started: 
> where
No thread specified.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird-rc1 FIXED IN: ladybird-rc1 INTEGRATED IN: ladybird-rc1 merlin-beta
14-06-2004

EVALUATION The suspend/resume fixes (for 4379031, etc.) changed the handling of external suspension of threads running _in_native. This was to fix a problem on NT where java -Xrunhprof:cpu=samples PepTest would hang, with a deadlock, due to suspending a thread that held the NT system memory free lock. The JPDA agents (used by jdb) count on having threads in native code suspend before returning from the suspend request. This includes any thread which is running agent code, including both agent threads and java threads which are running in the eventHook. The JPDA agent logic is: suspendor: grab all rawmonitors used by agent threads suspend one or all threads free all rawmonitors
11-06-2004

SUGGESTED FIX The fix was to return the JVMDI and JVM_Suspend code to their expected behavior - immediate suspension of threads in native code, with the existing inherent risk of deadlock on system locks. The JVMPI code alone will use the new model of suspending a native thread when it does a state transition out of native. For the 2.0 release we should revisit this one to look closely both at perhaps just doing external suspends at transitions into _java as well as handling both regular and raw monitor acquisition by "suspended" threads. karen.kinnear@East 2001-01-30 To clarify, for ladybird-beta, this bug was FIXED by rolling back the JVMPI set of suspend/resume fixes. For ladybird-rc1 this bug has been fixed on top of the JVMPI suspend/resume fixes.
11-06-2004