Initial Commit
[packages] / xemacs-packages / jde / doc / html / jdebug-ug / jdebug-ug-content.html
1 <html>
2
3 <head>
4 <meta http-equiv="Content-Type"
5 content="text/html; charset=iso-8859-1">
6 <meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
7 <title>JDEbug User's Guide</title>
8
9 <style TYPE="text/css">
10    h1 { font-family: sans-serif; font-size: x-large;}
11    h2 { font-family: sans-serif; font-size: large;
12         margin-left: .2in}
13    h3 { font-family: sans-serif; font-size: medium;
14         margin-left: .2in}
15    h4 { font-family: sans-serif;
16         margin-left: .2in}
17    p  { margin-left: .2in}
18    pre {margin-left: .4in}
19    ul { margin-left: .4in}
20    ol { margin-left: .45in}
21    li { margin-bottom: 2%}
22    table { margin-left: .2in}
23 </style>
24
25 </head>
26
27 <body bgcolor="#FFFFFF">
28
29 <h1>JDEbug User's Guide</h1>
30
31 <a name="AboutJDEbug">
32 <h2>About JDEbug</h2>
33 </a>
34
35 <p>JDEbug is a Java debugger that comes with the Java Development
36 Environment for Emacs. It permits you to execute a Java program
37 step-by-step and display and modify the program's internal state.
38 JDEbug features include:</p>
39
40 <ul>
41     <li>Source-level debugging. JDEbug maintains a source line
42         pointer that moves as you step through a program. You can
43         also set breakpoints in source buffers.<br>
44         </li>
45     <li>Automatic local variable display. JDEbug displays the
46         values of local variables as you step through source code
47         and when the target process stops at a breakpoint.<br>
48         </li>
49     <li>Object browsing. You can expand the local variable
50         display to show object fields to any depth.<br>
51         </li>
52     <li>Stack navigation. At each program step and breakpoint,
53         you can move up or down the stack with a single command.
54         The JDE moves the source cursor to the current line in
55         the current stack frame and displays the local variables
56         in that frame.<br>
57         </li>
58     <li>Multiprocess debugging. You can control execution and
59         display the internal state of multiple, independent
60         processes in the same debug session.<br>
61         </li>
62     <li>Expression evaluation. You can evaluate any expression
63         that is valid at the current suspension point.<br>
64         </li>
65     <li>Method tracing. The debugger optionally lists enties and/or
66         exits from all methods of specified classes. You can
67         define filters to eliminate unwanted traces.<br>
68         </li>
69     <li>Exception tracing. The debugger optionally lists all
70         exceptions of specified types. You can define filters to
71         eliminate unwanted traces.</li>
72 </ul>
73
74 <a name="JDEbugRequirements">
75 <h2>JDEbug Requirements</h2>
76 </a>
77
78 <p>JDEBug requires a virtual machine that conforms to the
79 specifications of the <a
80 href="http://java.sun.com/products/jpda/" target="content">Java
81 Debug Platform Architecture</a> (JPDA) defined by Sun
82 Microsystems. Starting with version 1.3, the vm shipped with Sun's Java SDK for Windows and Solaris conform to the JPDA specification.</p>
83
84 <p>In addition, JPDA backward compatibility packages are
85 available for Sun's Java SDK 1.2.2 for Windows and Linux platforms, respectively, and for the Reference Version of the SDK 1.2.2 for the Solaris platform.</p>
86
87 <p><strong>Note</strong> JPDA does not work reliably with the Production Version of the SDK 1.2.2 for Solaris. For example, attempting to attach to a process on the Production Version results in the following error:</p>
88
89 <p>
90 <pre>
91 Error [4] in accept() call!
92 err:: Interrupted system call
93 Socket transport failed to init.
94 dt_socket transport error; accept failed, rc = -1
95 </pre>
96 </p>
97
98 <p>If you want to use JDEbug on Solaris, you must use it with the Solaris Reference Version of SDK 1.2.2 or with the Solaris version of SDK 1.3.</p>
99
100 <p>The SDK 1.2.2 for Linux includes the JPDA components. You must download the JPDA compatibility packages for the Windows and Solaris versions of SDK 1.2.2 from the JPDA website.</p>
101
102 <p><strong>Note</strong> The JDE also provides a source-level
103 debugging interface to <code>jdb</code>, the command-line
104 debugger that comes with all version's of Sun's Java SDK. You can
105 use this interface to debug applications running on Sun vm's that
106 do not support the JPDA specification. See <a
107 href="../../ug/jdb-guide.html" target="jdb-guide">Debugging with
108 jdb</a> for more information.</p>
109
110 <a name="JDEbugandHotSpot">
111 <h3>JDEbug and HotSpot</h3>
112 </a>
113
114 <p>JPDA does not run reliably when a vm is operating in HotSpot mode. For example, JPDA sometimes fails to stop the debuggee process at breakpoints and has trouble getting the this object of the method in which the debuggee process is currently suspended.  Sun's JPDA development team is aware of this problem and is working to provide a solution. Meanwhile, you can work around the problem by running the vm in "classic" mode. See <a href="#ClassicMode">Launching an Application in Classic Mode</a> for more information.</p>
115
116
117 <a name="SettingUpJDEbug">
118 <h2>Setting Up JDEbug</h2>
119 </a>
120
121 <p>
122 Setting up JDEbug entails the following tasks:
123 </p>
124
125 <ul>
126   <li>
127     <a href="#SelectingJDEbug">Select JDEbug as your debugger.</a>
128   </li>
129   <li>
130     <a href="#SpecifyJPDALocation">Specify the location of the JDK's JPDA libraries.</a>
131   </li>
132   <li>
133     <a href="#SpecifySourceLocation">Specify the locations of Java source files on your system.</a>
134   </li>
135 </ul>
136
137 <p>The following sections explain how to perform these tasks.</p>
138
139 <a name="SelectingJDEbug">
140 <h3>Selecting JDEbug As Your Debugger</h3>
141 </a>
142
143 <p>The JDE is configured by default to serve as a source-level
144 debugger front-end to jdb, the command-line debugger that comes
145 with Sun's Java SDK. To use JDEbug, you must set the value of the
146 JDE customization variable <code>jde-debugger</code> to
147 specify JDEBug. To do this,</p>
148
149 <ol>
150  <li>Type <code>M-x customize-variable</code>.
151         
152         <p style="margin-left: 0em">
153           Emacs displays a customization buffer for <code>jde-debugger.</code>
154         </p>
155     <p style="margin-left: 0em">
156           <img src="images/enable_jdebug.gif" width="572" height="149">
157         </p>
158  </li>
159  <li>
160    Click the radio button next to JDEbug.<br>
161  </li>
162  <li>
163    Click the <strong>State</strong> button and select <strong>Save
164    for Future Sessions</strong> if you want to enable JDEbug
165    for all projects or <strong>Set for Current Session</strong>
166    if you want to enable JDEbug only for the current project,
167    in which case you should save the setting in your project
168    file.
169  </li>
170 </ol>
171
172 <p>Select any Java source buffer. The JDEBug menu should appear 
173 in the Emacs menubar.</p>
174
175 <p>
176 <img src="images/jdebug_menu.gif"></p>
177
178 <a name="SpecifyingJPDALocation">
179 <h3>Specifying the Location of the JPDA Libraries</h3>
180 </a>
181
182 <p>JDEbug uses class and native code libraries that implement the JPDA specification. You must tell JDEbug where these support libraries live. The way to do this depends on the platform and version of the Sun Java SDK you are using.</p>
183
184 <a name="SDK1.3WindowsSolaris">
185 <h4>Sun Java SDK 1.3 for Windows and Solaris</h4>
186 </a>
187
188 <p>To specify the location of the JPDA support libraries for Sun's Java SDK 1.3:</p>
189
190 <ol>
191     <li>Select <strong>JDEbug-&gt;Preferences</strong> to display
192         a customization buffer for JDEbug variables.
193         </li><br><br>
194     <li>Customize the entries for the following variables (see 
195        <a href="../../ug/jde-ug-content.html#CustomizingJDE">Customizing the JDE</a>).
196     <table border="0"
197         cellpadding="5" width="100%">
198             <tr>
199                 <th align="left" width="30%">Variable</th>
200                 <th align="left" width="70%">Set to...</th>
201             </tr>
202             <tr>
203                 <td width="30%"><code>jde-bug-vm-includes-jpda-p</code></td>
204                 <td width="70%">On.</td>
205             </tr>
206             <tr>
207                 <td valign="top" width="30%"><code>jde-bug-jdk-directory</code></td>
208                 <td width="70%">Directory that contains the Java SDK 1.3. 
209                 Suppose that the SDK is installed in the directory 
210                 <code>d:\jdk-1.3</code> on your system. Then you would 
211                  set <code>jde-bug-jdk-directory</code> to <code>d:\jdk-1.3</code>.</td>
212             </tr>
213         </table>
214     </li><br>
215 </ol>
216
217 <a name="SDK1.2.2">
218 <h4>Java SDK 1.2.2 for Windows, Linux, and Solaris</h4>
219 </a>
220
221 <p>To specify the location of the JPDA support libraries for Sun's Java SDK 1.2.2:</p>
222
223 <ol>
224     <li>Select <strong>JDEbug-&gt;Preferences</strong> to display
225         a customization buffer for JDEbug variables. <br>
226         </li><br><br>
227     <li>Customize the entries for the following variables (see 
228        <a href="../../ug/jde-ug-content.html#CustomizingJDE">Customizing the JDE</a>). <br>
229         <table border="0" cellpadding="5" width="100%">
230             <tr>
231                 <th align="left" width="30%">Variable</th>
232                 <th align="left" width="70%">Set to...</th>
233             </tr>
234             <tr>
235                 <td width="30%"><code>jde-bug-vm-includes-jpda-p</code></td>
236                 <td width="70%">Off.</td>
237             </tr>
238             <tr>
239                 <td valign="top" width="30%"><code>jde-bug-jpda-directory</code></td>
240                 <td width="70%">Directory that contains the JPDA package.</td>
241             </tr>
242         </table>
243     </li><br>
244     <li>
245         Include the directory containing the JDPA native code libraries
246         (e.g., <code>jdwp.dll</code>) in your system's library load path.
247         The libraries live in different places, depending on the platform:
248         <ul><br>
249           <li>
250             On Windows, the libraries live in the JPDA backward compatibiliy package's 
251             <code>bin</code> directory. So add the <code>bin</code> directory to your 
252              system's path environment variable.
253             <p style="margin-left: 0em">
254              For example, suppose the JPDA directory resides in the directory <code>c:/jpda</code>
255              on your Windows 95 system. In this case, you would include the following line
256              in your <code>autoexec.bat</code> file:
257              </p>
258              <p>
259                <code>set path=c:/jpda/bin;%path%</code>
260              </p>
261           </li>
262           <li>On Solaris, the libraries live in the JPDA's <code>lib/sparc</code>
263                subdirectory. So add the <code>lib/sparc</code> subdirectory to the 
264                <code>LD_LIBRARY_PATH</code> environment variable of
265               the Emacs process. The easiest way to do this is to include the setting in
266               your <code>.bashrc</code> or <code>.cshrc</code> file.             
267               <p style="margin-left: 0em">
268                 For example, suppose you install the JPDA directory at <code>/home/me/jpda</code> on 
269                 your system. Then you would add the following line to your <code>.cshrc</code>
270                 file:
271                 <p>
272                   <code>setenv LD_LIBRARY_PATH 
273                      /home/me/jpda/lib/sparc:$LD_LIBRARY_PATH</code>
274                 </p>
275            </li>
276            <li>
277              On Linux, the JDPA libraries live in the Java SDK 1.2.2's <code>lib/sparc</code>
278              (Sun processor) or <code>lib/i386</code> (Intel processor) subdirectory. So for Linux,
279              you would add lines similar to the following to your <code>.bashrc</code> file:
280              <p>
281                   <code>LD_LIBRARY_PATH = /opt/jdk1.2.2/lib/i386:$LD_LIBRARY_PATH</code><br>
282                   <code>export LD_LIBRARY_PATH</code>
283              </p>
284              
285              <p>Also make sure that there are symbolic links for libjdwp.so and
286                 libdt_socket.so as follows:
287
288                 <p>
289                  <code>jdk1.2.2/lib/libjdwp.so</code>  -&gt; <code>jdk1.2.2/lib/i386/libjdwp.so</code><br>
290                  <code>jdk1.2.2/lib/libdt_socket.so</code> -&gt; <code>jdk1.2.2/lib/i386/libdt_socket.so</code>
291                 </p> 
292              </p>
293
294
295           </li>
296         </ul>
297     </li><br><br>
298 </ol>
299
300 <a name="SpecifySourceLocation">
301 <h3>Specifying the Location of Source Files</h3>
302 </a>
303
304 <p>
305 To display the current location in the program you are debugging, JDEBug needs to be able to find the source files from which the program was compile. The JDEbug looks for the files in the source directories specified by the JDE variable <code>jde-sourcepath</code>. Therefore, before starting a debugging session, you must ensure that this variable specifies all the source files that you may step through during the debugging session.
306 </p>
307
308 <p>
309 To set this variable:
310 </p>
311 <ol>
312   <li>
313     Type <code>M-x customize-variable jde-db-source-directories</code>
314     <p style="margin-left: 0em">
315      Emacs displays the customization buffer for the variable.
316     </p>
317   </li>
318   <li>
319    Edit the buffer to reflect the location of Java source files on your system.
320    <p style="margin-left: 0em">
321      <strong>Note</strong> You should specify only the root directories of the top-level packages you 
322      may need to visit during a debugging session. For example, suppose the source files for 
323      your current project reside in a subdirectory of the project directory named
324     <code>src</code> and the Java SDK source lives in <code>c:/java/j2sdk1.4.1/src</code>. Then
325     the customization buffer should appear as follows:
326
327     <p><img src="images/source_path.gif"></p>
328    </p>
329   </li>
330   <li>
331     Save the setting in your <code>.emacs</code> or <code>.prj</code> file
332     (see  <a href="../../ug/jde-ug-content.html#CustomizingJDE">Customizing the JDE</a>).
333 </ol>
334
335
336 <a name="StartingDebugger">
337 <h2>Starting the Debugger</h2>
338 </a>
339
340 <p>To start the debugger, select <strong>Processes-&gt;Start
341 Debugger</strong> from the JDEbug menu. This command simply
342 starts the debugger. To debug an application, you must either</p>
343
344 <ul type="disc">
345     <li>launch the application inside the debugger (see <a
346         href="#LaunchingProcess">Launching a Process</a>)</li>
347     <li>attach the debugger to the application if it was started
348         outside the debugger (see <a href="#AttachingProcess">Attaching
349         a Process</a>)</li>
350     <li>put the debugger in listen mode and start the application
351         outside the debugger (see <a href="#ListeningForProcess">Listening
352         for a Process</a>)</li>
353 </ul>
354
355 <a name="SetWorkingDirectory">
356 <h3>
357   Setting the Debug Session Working Directory
358 </h3>
359 </a>
360
361 <p>
362   The debugger launches all processes from the directory in which it was started.
363   This directory is known as the debug session working directory. By default, the
364   debug session working directory is the directory of the source buffer that was
365   active when you started the debugger. To specify another directory as the
366   working directory for the current debugger session, set the variable 
367   <code>jde-run-working-directory</code> to the directory's path.
368 </p>
369 <p>
370   <strong>Note</strong> You cannot set the working directory on a per-process basis.
371   All processes launched during the current session start in the debug session
372   working directory.
373 </p>
374
375 <a name="ExitingDebugger">
376 <h2>
377   Exiting the Debugger
378 </h2>
379 </a>
380
381 <p>To exit the debugger, select <strong>Exit Debugger</strong>
382 from the JDEbug menu. The JDE terminates any processes (vm's)
383 launched by the debugger and terminates the debugger process (vm)
384 itself.</p>
385
386 <p><strong>Note</strong> Exiting Emacs itself without first
387 exiting the debugger orphans the debugger vm and any processes (vm's)
388 launched by the debugger. Thus, it is important to exit JDEbug
389 before exiting Emacs.</p>
390
391 <a name="LaunchingProcess">
392 <h2>Launching a Process</h2>
393 </a>
394
395 <p>In this guide, a process refers to a running instance of an
396 application. JDEBug provides two commands for launching processes.</p>
397
398 <ul type="disc">
399     <li><strong>JDEbug-&gt;Processes-&gt;Launch Process</strong> 
400         <p style="margin-left: 0em">
401             This command launches an instance of the application whose
402         main class is specified by the variable <code>jde-run-application-class</code>,
403         or, if this variable is <code>nil</code>, the application
404         in the current Java source buffer. The debugger suspends the debuggee process
405         before it enters the application's main method.
406         At this point, you should set one or more breakpoints in the
407         application and select the Run command from the JDEbug menu.
408         The process will then run to the first breakpoint at which point you can
409         continue to the next breakpoint or single-step the process.<br>
410         </p>
411     </li>
412     <li><strong>JDE-&gt;Debug App</strong>
413           <p style="margin-left: 0em">
414             This command performs the following actions:<br>
415         </p>
416         <ol>
417             <li>Starts the debugger, if necessary.</li>
418             <li>Launches the application.</li>
419             <li>Sets any breakpoints you have previously
420                 specified (see Setting Breakpoints).</li>
421             <li>Runs the application.</li>
422         </ol>
423         <p><strong>Note</strong> With this command, the
424         application will simply run to completion without
425         stopping, if you have not previously specified any valid
426         breakpoints for the application or none of the
427         breakpoints exist on the main execution path.</p>
428     </li>
429 </ul>
430
431 <p>Issuing either of these commands cause JDEBug to split your
432 Emacs frame into two windows and to display a separate
433 local variables frame.</p>
434
435 <p>.<img src="images/window_config.gif"></p>
436
437 <p>The top Emacs window displays a Java source buffer. The source
438 buffer displays either the source buffer where you launched the
439 application or, if you used the <strong>Debug App</strong>
440 command, the source buffer containing the first breakpoint hit
441 after the application was launched.</p>
442
443 <p>The bottom window contains the debugger messages buffer for
444 the process that was just launched. This buffer displays messages
445 regarding the status of the process being debugged.</p>
446
447 <p>The local variables frame displays the application process's local
448 variables. Initially, the frame displays the local variables in the
449 stack frame of the breakpoint hit when you launched the
450 application. If your application does not hit a breakpoint at
451 startup, the local variables buffer displays nothing.</p>
452
453 <p>At this point, if the process was launched successfully and
454 did not run to completion, you can begin debugging your
455 application.</p>
456
457 <p><strong>See Also</strong></p>
458
459
460 <p><a href="#ProcessBuffers">Working with Process Buffers</a></p>
461
462
463
464 <p><a href="#DebuggingMultipleProcesses">Debugging Multiple Processes</a></p>
465
466
467 <a name="ClassicMode">
468 <h3>Launching an Application in Classic Mode</h3>
469 </a>
470
471 <p>Depending on the version of the JDK you are using, the debugger can launch a debuggee process in either of two modes:<p>
472
473 <ul>
474   <li>classic
475       <p>Uses just-in-time (JIT) compilation of classes to
476          speed up execution of a program. This is the mode
477          used in early versions of the JDK. Hence its name.</p> 
478   </li>
479   <li>HotSpot
480       <p>Speeds up execution by detecting and compiling heavily used fragments 
481       of code (hot spots). Unfortunately, the JPDA does not work reliably
482       in this mode (see <a href="#JDEBUGandHotSpot">JDEbug and Hotspot</a>). 
483       Therefore, you should use classic mode to launch a debuggee application.
484       </p>
485   </li>
486 </ul>
487
488 <p> The debugger launches applications in HotSpot mode by default. To launch
489 an application in classic mode, type <code>M-x customize-variable 
490 jde-run-classic-mode-vm</code> and toggle the variable on.</p>
491
492 <p><strong>Note</strong> If the JDK's Java Runtime Environment (JRE) is installed on your system, JPDA sometimes uses the vm installed in the JRE's bin directory to launch the debuggee application. (I'm not sure exactly how the JDPA determines which vm to use to launch a debuggee application. It seems to vary from system to system.) Unfortunately, on Windows, at least, the JDK installer installs only the HotSpot vm in the JRE bin directory. If you want to debug applications, you must manually install the classic mode vm in the JRE bin directory itself. To do this, simply copy the classic subdirectory from the jre subdirectory of the JDK to the bin subdirectory of the JRE. After you have done this, the JRE bin directory should look similar to the following:</p>
493
494 <p>
495 <pre>
496     - c:\Program Files\
497       - JavaSoft
498         - bin
499             classic
500             hotspot
501       + lib
502 </pre>
503 </p>
504
505 <a name="ConnectingToExternalProcesses">
506 <h2>Connecting to External Processes</h2>
507 </a>
508
509 <p>
510 JDEbug supports two ways of connecting to an application that it does not itself launch: attach mode and listen mode. Each of these modes can be thought of as an interaction between a client and a server. In attach mode, the application vm is the server and JDEbug is the client. In listen mode, JDEbug is the server and the application vm is the client. The advantage of attach mode is that it allows you to connect (and reconnect) to an external process at any time. The advantage of listen mode is that it allows you to debug the startup of an external process.
511 </p>
512
513 <p>
514 To use either of these modes, you must start the application vm with certain command line arguments and then issue a JDEbug command to establish the connection. The following sections explain the procedurs for establishing an attach-mode and listen-mode connection, respectively.
515 </p>
516
517
518 <a name="AttachingProcess">
519 <h3>Attaching a Process</h2>
520 </a>
521
522 <p>
523   JDEbug allows you to attach the debugger to an existing local
524   or remote process that was launched outside the current debugger
525   session. This is useful for debugging servlets and processes that
526   were launched by another application, for example, servelets.
527 </p>
528 <p> 
529 <strong>Note</strong>You can use <strong>JDE-&gt;Run App</strong>
530  to launch the third-party application. Use the JDE variables 
531 <code>jde-run-executable</code> and <code>jde-run-executable-args</code>
532 to cause the <strong>Run App</strong> command to run a non-Java app that
533 launches a Java subprocess to be debugged.
534 </p>
535 </p>
536
537 <p>
538   You can attach the debugger to an existing process via: 
539   <ul>
540    <li>
541      a socket
542    </li>
543    <li>
544      shared memory, if both processes run
545      on the same host
546    </li>
547   </ul>
548 </p>
549 <p>
550   The shared memory option is available only on
551   Windows. It is much faster and thus is preferable. In either case
552   the existing process must have been started with the appropriate
553   debug options.
554 </p>
555
556 <a name="AttachViaSocket">
557 <h4>
558   Attaching via a Socket
559 </h4>
560 </a>
561
562 <p>To attach via a socket:</p>
563
564 <ol type="1" start="1">
565   <li> 
566     Launch the debuggee process with the following vm command
567     line arguments:
568
569     <ul>
570       <li><code>-Xdebug</code></li>
571       <li><code>-Xnoagent</code></li>
572       <li><code>-Djava.compiler=NONE</code></li>
573       <li><code>-Xrunjdwp:transport=dt_socket,address=NNNN,server=y,suspend=n</code>
574         <p style="margin-left: 0em">
575           where <code>NNNN</code> is any unused socket address on the host
576           processor for the debuggee process.
577         </p>
578         <p  style="margin-left: 0em">
579           See <code>jde-run-option-vm-args</code> for information on how 
580           to specify vm arguments when launching an application from the JDE.
581         </p>
582       </li>
583     </ul>
584   </li>
585   <li>
586       Execute JDEbug-&gt;Processes-&gt;Start Debugger to start the
587       debugger (if necessary).
588   </li>
589   <li>
590     <strong>Execute JDEbug-&gt;Processes-&gt;Attach Process-&gt;Local Host</strong>
591     or <strong>Remote Host</strong> to attach the debugger to a local or remote 
592     process, respectively.
593     <p style="margin-left: 0em">
594       In the first case, the JDE prompts you to enter the socket 
595          address that you specified in step 1. In the second case, 
596          the JDE also prompts you to enter the name of the host on 
597          which the remote process is running.
598     </p>
599   </li>
600 </ol>
601
602 <a name="AttachViaSharedMemory">
603 <h4>
604   Attaching via Shared Memory
605 </h4>
606 </a>
607
608 <p>
609   To attach via shared memory:
610 </p>
611
612 <ol>
613   <li>
614       Launch the debuggee process with the following vm command
615       line arguments:
616       <ul>
617         <li><code>-Xdebug</code></li>
618         <li><code>-Xnoagent</code></li>
619         <li><code>-Djava.compiler=NONE</code></li>
620         <li><code>-Xrunjdwp:transport=dt_shmem,address=NAME,server=y,suspend=n</code>
621          <p  style="margin-left: 0em">
622           where <code>NAME</code> is a string identifying the process, e.g.,
623           <code>webserver</code>.
624          </p>
625          <p style="margin-left: 0em">
626           See <code>jde-run-option-vm-args</code> for
627           information on how to specify vm arguments when launching
628           an application from the JDE.
629          </p>
630         </li>
631     </ul>
632   </li>
633   <li>
634       Execute <strong>JDEbug-&gt;Processes-&gt;Start Debugger</strong>
635       to start the debugger (if necessary).
636   </li>
637   <li>
638       Execute <strong>JDEbug-&gt;Processes-&gt;Attach Process-&gt;Via
639       Shared Memory</strong> to attach the debugger to the process
640       started in step 1.
641     <p style="margin-left: 0em">
642       The JDE prompts you to enter the <code>NAME</code>
643       you specified in step 1.
644     </p>
645   </li>
646 </ol>
647
648 <p><strong>Note</strong> You can attach/detach from a
649 running process as many times as you want during a session.</p>
650
651 <a name="ListeningForProcess">
652 <h3>Listening for a Process</h3>
653 </a>
654
655 <p>
656 JDEbug's listen mode enables a process that is launched independently of JDEbug 
657 to attach itself to JDEbug when the independently launched process starts.
658 Listen mode is useful for debugging the startup code of processes that JDEbug
659 cannot launch itself. Examples of such processes are processes launched by other
660 applications such as a web server or a hybrid C/Java application where a C 
661 main program uses an embedded vm to to run Java processes.
662
663 <p> 
664 <strong>Note</strong>You can use <strong>JDE-&gt;Run App</strong>
665  to launch the third-party application. Use the JDE variables 
666 <code>jde-run-executable</code> and <code>jde-run-executable-args</code>
667 to cause the <strong>Run App</strong> command to run a non-Java app that
668 launches a Java subprocess to be debugged.
669 </p>
670 </p>
671
672 <p>
673 When in listen mode, JDEbug acts as a debug server, listening for
674 debug service requests from independently launched processes.  You can
675 cause JDEbug to use either a socket or a shared memory channel
676 (Windows only) to communicate with processes requesting debug
677 services. You must use the socket option, if you want to debug a
678 process running on a remote machine or you are running the debugger
679 under Unix, On Windows, you can use either option to debug processes
680 running on the local machine. However, the shared memory option
681 typically results in faster response to debug commands.
682 </p>
683
684 <a name="ListenOnSocket">
685 <h4>Listening on a Socket</h4>
686 </a>
687
688 <ol>
689   <li>
690       Execute <strong>JDEbug-&gt;Processes-&gt;Start Debugger</strong>
691       to start the debugger (if necessary).
692     
693   </li>
694   <li>
695     Select <strong>JDEbug-&gt;Processes-&gt;Listen on-&gt;Socket</strong>
696     to put JDEbug in listen mode.
697
698       <p style="margin-left: 0em">
699       This command causes the debugger to listen on the socket
700       specified by the JDE variable <code>jde-bug-server-socket</code>. The
701       default value is <code>2112</code>. You can customize this variable
702       to specify any socket address you choose or to cause JDEbug to prompt you to
703       enter an address. Whatever address you choose, you must enter the same address
704       as an argument of the command that launches the process to be debugged.
705       </p>
706   </li> 
707   <li> 
708     Launch the debuggee process with the command line arguments required
709     to attach to JDEbug.
710     <p style="margin-left: 0em">
711     See <a href="#ListenModeVMArgs">Listen Mode VM Arguments</a> for more
712     information.
713     </p>
714   </li>
715 </ol>
716
717 <p>
718 When you launch a Java application with listen mode arguments, the vm
719 halts before running the app's main method and attempts to connect
720 with JDEbug. Once the connection is made, JDEbug is in
721 complete control of the app. For example, the app won't run until
722 the debugger issues a continue command. This means you can set
723 breakpoints in the debuggee app's startup code. 
724 </p>
725
726 <a name="ListenOnSharedMemory">
727 <h4>Listening on a Shared Memory Channel</h4>
728 </a>
729
730 <p><strong>Note</strong> This option is available only if both the debugger
731 and the debuggee process are running under Windows on the same machine.</p>
732
733 <ol>
734   <li>
735       Execute <strong>JDEbug-&gt;Processes-&gt;Start Debugger</strong>
736       to start the debugger (if necessary).
737     
738   </li>
739   <li>
740     Select <strong>JDEbug-&gt;Processes-&gt;Listen on-&gt;Shared Memory</strong>
741     to put JDEbug in listen mode.
742
743       <p style="margin-left: 0em">
744       This command causes the debugger to listen on the shared memory channel
745       specified by the JDE variable <code>jde-bug-server-shmem-name</code>. The
746       default value is <code>jdebug</code>. You can customize this variable
747       to specify any name you choose or to cause JDEbug to prompt you to
748       enter a name. Whatever name you choose, you must enter the same name
749       as an argument of the command that launches the process to be debugged.
750       </p>
751   </li> 
752   <li> 
753     Launch the debuggee process with the command line arguments required
754     to attach to JDEbug.
755     <p style="margin-left: 0em">
756     See <a href="#ListenModeVMArgs">Listen Mode VM Arguments</a> for more
757     information.
758     </p>
759   </li>
760 </ol>
761
762 <p>
763 When you launch a Java application with listen mode arguments, the vm
764 halts before running the app's main method and attempts to connect
765 with JDEbug. Once the connection is made, JDEbug is in
766 complete control of the app. For example, the app won't run until
767 the debugger issues a continue command. This means you can set
768 breakpoints in the debuggee app's startup code. 
769 </p>
770
771 <a name="ListenModeVMArgs">
772 <h4>Listen Mode VM Arguments</h4>
773 </a>
774
775 <p>
776   Use the following vm arguments when launching a process to be debugged in listen mode.
777   <ul>
778     <li>
779       <code>-Xdebug</code>
780     </li>
781     <li>
782       <code>-Xnoagent</code></li>
783    <li><code>-Djava.compiler=NONE</code></li>
784    <li>
785      <code>-Xrunjdwp:transport=dt_socket,address=NNNN,server=n,suspend=y</code>
786      <p style="margin-left: 0em">
787         where <code>TRANSPORT</code> is either <code>dt_socket</code> or
788         <code>dt_shmem</code> and <code>NNNN</code> is any symbolic name you want
789         to use for the shared memory channel or any unused socket address on the host
790         processor for the debuggee process.
791      </p>
792    </li>
793    <li>
794       <code>-Xbootclasspath:JDKHOME/jre/lib/rt.jar;JDKHOME/lib/tools.jar</code>
795       <p style="margin-left: 0em">
796          where JDKHOME is the home directory for the JDK.
797       </p>
798       <p style="margin-left: 0em">
799         <strong>Note</strong> This option is necessary only if you are
800         using the JDK 1.3 vm to launch the debuggee process.
801       </p>
802     </li>
803   </ul>
804  </p>
805
806 <p>
807   Here is an example of a typical command line to launch a debuggee
808   client, using JDK1.3:
809   <p>
810    <code>java -classpath d:/myapp/myapp.jar -Xdebug -Xnoagent</code><br>
811    <code>-Xrunjdwp:transport=dt_socket,address=jdebug,server=n,suspend=y</code><br>
812    <code>-Xbootclasspath:e:/jdk1.3/jre/lib/rt.jar;e:/jdk1.3/lib/tools.jar</code><br>
813    <code>com.myorg.myapp.Main</code>
814   </p>
815   </p>
816 <p>
817       Use the JDE variable <code>jde-run-option-vm-args</code>
818      to specify vm arguments when launching an application from the JDE.
819 </p>
820
821 <a name="DebuggingMultipleProcesses">
822 <h2>Debugging Multiple
823 Processes</h2>
824 </a>
825
826 <p>
827 JDEbug allows you to launch and debug multiple debuggee processes during the same debugger session. JDEbug assigns a numeric identification number to each process that it launches or attaches in either attach or listen mode. All JDEbug commands, except those that launch or attach processes, implicitly address a process called the <i>target process</i>. When you launch or attach a process, that process becomes the target process until you specify a different process as the target process.</p>
828
829 <p>To specify a different process as the target process, select <strong>JDEbug-&gt;Processes-&gt;Set Target Process</strong>, then enter the ID of the target process at the prompt.
830 </p>
831
832 <a name="ProcessBuffers">
833 <h2>Working with Process Buffers</h2>
834 </a>
835
836 <p>JDEbug creates a set of buffers for each process that you
837 debug during a debugger session. </p>
838
839 <table width=100% >
840   <colgroup span=2>
841     <col width=25% align=left valign=top></col>
842     <col width=75% align=left valign=top></col>
843   </colgroup>
844   <thead>
845     <tr>
846       <th>Buffer</th>
847       <th>Description</th>
848     </tr>
849   </thead>
850   <tbody>
851     <tr>
852       <td>Process</td>
853       <td>Displays status messages from the debugger.</td>
854     </tr>
855     <tr>
856       <td>Local Variables</td>
857       <td>
858           Displays the values of local variables and the
859           fields of the object on which the current method
860           was invoked (the implicit this object). This buffer
861           is off by default. 
862        </td>
863     </tr>
864     <tr>
865       <td>Command Line Interface (CLI)</td>
866       <td>
867           Allows you to interact with a process that has a command
868           line interface (CLI). The JDE sends lines that you type in this
869           buffer to the process's standard input. The process's standard
870           output also appears in this buffer. 
871        </td>
872     </tr>
873
874     <tr>
875       <td>Threads</td>
876       <td>
877           Displays the current status of all threads created by the
878           debuggee process. The <strong>JDEbug-&gt;Display-&gt;Threads</strong>
879           command creates this buffer.
880        </td>
881     </tr>
882
883     <tr>
884       <td>*JDEbug*</td>
885       <td>
886           Displays the low-level commands sent by Emacs to the Java backend
887           of JDEbug, the backend's responses to those commands, and events
888           detected by the backend. You should always include a copy of this
889           buffer in bug reports as it represents a complete record of your
890           debugs session.
891        </td>
892     </tr>
893
894
895   </tbody>
896 </table>
897
898 <a name="DisplayBuffers">
899 <h3>Displaying the Buffers</h3>
900 </a>
901
902 <p>
903 JDEbug displays the Process and Locals buffer in windows in the current frame when you launch or attach a process.</p>
904
905 <ul>
906   <li> 
907     To replace one of these buffers with another, select the buffer from the 
908     <strong>JDEbug-&gt;Show Buffers</strong> menu.
909   </li>
910   <li>
911     To display a buffer in a separate frame, select the buffer and
912     then select <strong>Files-&gt;Make New Frame</strong>.
913   </li>
914   <li>
915     To display the startup window configuration for a process, select
916     <strong>JDEbug-&gt;Processes-&gt;Set Target Process</strong>
917      and enter the process's ID number.
918   </li>
919 </ul>
920
921 <a name="DeleteBuffers">
922 <h3>Deleting Buffers</h3>
923 </a>
924
925 <p>
926 JDEbug does not delete the buffers belonging to a process when it dies. To delete all the buffers created for dead processes, select 
927 <strong>JDEbug-&gt;Processes-&gt;Remove Dead Processes</strong>. This command removes all traces of the dead processes from the Emacs environment.
928 </p>
929
930 </body>
931 </html>