JDK-4369489 : jdb does not work on Linux platform.
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0,1.3.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2000-09-08
  • Updated: 2002-08-30
  • Resolved: 2002-08-30
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 rc2Fixed 1.4.0Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
Name: tb29552			Date: 09/08/2000

java version "1.3.0beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0beta_refresh-b09)
Java HotSpot(TM) Client VM (build 1.3.0beta-b07, mixed mode)

Start the java debugger with the command: jdb <java class file> <command line>.
It loads and prints:

Initializing jdb...
*** Reading commands from /home/kpratt/.jdbrc
> *** Reading commands from /home/kpratt/.jdbrc
> >
Now, I type 'run' and get:

run <java class file and command line I supplied above>
VM Started:
>
I type 'threads' and the debugger hangs.  Also, the java class file being
debugged does not seem to actually run.  Print statements that work when run
with the java command do not work when run under the jdb.
(Review ID: 107920) 
======================================================================

al.smith@eng 2001-04-10

Regression tests:
com/sun/jdi/FilterMatch.java
com/sun/jdi/FilterNoMatch.java
are failing with Ladybird build 19 on Linux 6.2 host d-ucup02-123-253
Most of the time they fail. However, these tests will intermittently 
pass. Note: This test does not have a timeout value specified and uses 
the default of 2 minutes provided by jtreg.
See Bug # 4427363
al.smith@eng 2001-04-26
Verified in Merlin b61 and Ladybird b23

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

EVALUATION tim.bell@Eng 2000-09-12 See attached trace files of debugger start up when using hotspot VM versus classic VM. In both cases the debugger sends EventRequests asking for: 1) report all exceptions 2) report all thread start events 3) report all thread end events These are all acknowleged by the debugee. Then a VirtualMachine.Resume is sent. In the case of the classic VM, we get back a Thread Start event, followed by the ACK of the VirtualMachine.Resume: [JDI: Receiving Command(id=1) JDWP.Event.Composite] [JDI: Receiving: suspendPolicy(byte): 2] [JDI: Receiving: events(Events[]): ] [JDI: Receiving: events[i](Events): ] [JDI: Receiving: eventKind(byte): 6] [JDI: Receiving: requestID(int): 7] [JDI: Receiving: thread(ThreadReferenceImpl): ref=1] In the hotspot case, all that is received is the ACK of the VirtualMachine.Resume. Thus jdb is left waiting for a debugee thread to start up. daniel.daugherty@Eng 2001-02-02 updated 2001-02-09 The above entry is for bits that don't contain Karen's suspend/resume fix. That failure mode is the first layer of the onion. The second layer of the onion is being tracked by the following bug: 4413752 2/1 Linux: suspended thread blocks raw ObjectMonitor entry My original evaluation notes for this portion of the bug are attached as eval-4413752.
11-06-2004

WORK AROUND Name: tb29552 Date: 09/08/2000 Run the original program with the java command and enable remote debugging. Attach to the already running VM with the jdb running in a seperate VM. ====================================================================== Refer to http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/jdb.html for more documentation on using jdb. Here is an example: In one process, start up the debugee class and ask it to wait: % java -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y HelloWorld In another process, start up jdb and attach to the socket at address 8000: % jdb -attach 8000 You may then proceed with your debugging session. tim.bell@Eng 2000-09-12 An additional workaround: specify that the debugee should be run using the classic VM: % jdb -tclassic HelloWorld Initializing jdb... > stop at HelloWorld:3 Deferring breakpoint HelloWorld:3. It will be set after the class is loaded. > run run HelloWorld > VM Started: Set deferred breakpoint HelloWorld:3 Breakpoint hit: thread="main", HelloWorld.main(), line=3, bci=0 3 System.out.println("Hello world!"); main[1] threads Group system: (java.lang.Thread)0x89 Signal dispatcher cond. wait (java.lang.ref.Reference$ReferenceHandler)0x88 Reference Handler cond. wait (java.lang.ref.Finalizer$FinalizerThread)0x87 Finalizer cond. wait Group main: (java.lang.Thread)0x1 main running (a main[1] cont > Hello world! The application exited tim.bell@Eng 2000-09-12
12-09-2000