At 01:06 PM 11/15/99 -0500, you wrote:
>Paul
>
>My LD_LIBRARY_PATH was not setup as you guessed. When I added
>/usr/local/jpda/lib/sparc,
>I did get better results, but there must be other problems.
>
>Here's the environment variables that I've set :
>LD_LIBRARY_PATH=/usr/local/jpda/lib/sparc:/oracle/product/oibill1t/lib
>PATH=/usr/local/jpda/bin:/usr/java1.2/bin:/usr/dt/bin:/usr/openwin/bin:/bin:
>/usr/bin:/usr/ucb:/usr/local/bin:/usr/sbin:/usr/xpg4/bin:/export/home/dm4356
>/bin:/usr/local/netscape-4.7-40bit:/oracle/product/oibill1t/bin
>
>I never seem to be able to set a breakpoint without an error message.
That's because there's an XEmacs compatibility bug. The JDEbug beta uses an
Emacs function that is not defined by Emacs (see below). You have a choice.
Either find the XEmacs equivalent and modify the JDE soure to use this
function or wait until I get around to doing this msyself. This could be
some time as my priority is to finish the Emacs version of JDEBug first and
worry about XEmacs compatibility later.
If you're really intend on using JDEbug during the beta phase and don't
have the time, expertise, or inclination to fix XEmacs-related bugs
yourself, you would be better off using Emacs.
>Even though I have Db Read App Args toggled on, I never get prompted to
>specify args. (If I use the jdb, this feature works.)
This is a jdb function. I don't think I've implemented if for JDEbug yet.
>I'm not sure in what order to do things: start debugger from the JDEbug
>menu; Debug App from the JDE menu?
>Sometimes when I select continue a previously set breakpoint is honored but
>I'm unable to display any variables.
>
JDE->Debug App is a convenience function. It does a bunch of thing
automatically that you can do yourself from the JDEbug menu. This includes:
1) Starting the debugger, if necessary, i.e. JDEbug->Start Debugger
2) Launching the application to be debugged (the debuggee), i.e.,
JDEbug->Process->Launch Process.
3) Passing previously set breakpoints to the debugger, i.e., JDEbug->Set
Breakpoint.
4) Running the application, i.e., JDEbug->Continue, from the start.
>If I do things in the following order here's what happens:
>explicitly start debbuger
> Debugger succcessfully started.
>Debug App
> jdebug buffer
> java -classpath
>/export/home/dm4356/jde/d/jde-2.1.6beta11/java/lib/jde.jar:/usr/local/jpda/l
>ib/jpda.jar jde.debugger.Main
>
>
> (jde-dbo-init-debug-session)
>
> JDE> -1 1 launch 1 -use_executable java runtest
>
>
>
> (jde-dbo-message
> 1 "Launched VM Java Debug Interface (Reference
>Implementation) version 1.0
> Java Debug Wire Protocol (Reference Implementation) version
>1.0
> JVM Debug Interface version 1.0
> JVM version 1.2.1 (Solaris VM, build
>Solaris_JDK_1.2.1_04_pre-release, native threads, nojit)")
>
>
> (jde-dbo-command-result 1 35932)
This message indicates that the debugger was able to launch runtest. It has
assigned it a process id of 1 and has opened a socket numbered 35932 for
handling standard I/O between Emacs and runtest.
The Debug App command now issues a run command.
> JDE> 1 2 run
>
>
>
> (jde-dbo-event-set
> 1 "all"
> (list "Thread" 1 "main" "unknown" "suspended by debugger")
> (list 'jde-dbo-vm-start-event))
>
Start event indicating that the debugger has started runtest.
> java.lang.VerifyError:
>jde/debugger/Application.handleCommand(Ljava/lang/Integer;Ljava/lang/String;
>Ljava/util/List;)V at pc 831: stack height conflict: 0 vs. 1
>
> at jde.debugger.Jdebug.handleAppCommand(Jdebug.java:357)
> at jde.debugger.Jdebug.access$1(Jdebug.java:337)
> at jde.debugger.Jdebug$1.run(Jdebug.java:215)
>
At this point the vm running JDEbug has a problem with Jdebug.class. I
don't get this error on Solaris 5.6 with Classic VM (build JDK1.2.2-W,
native threads, sunwjit).
You could try recompiling the JDEbug source with the version of the JDK
your are using and rebuilding the jde.jar.
> runtest(1) buffer (runtest is the name of program)
> *** Debugger Output for Process runtest(1) ***
>
> Launched VM Java Debug Interface (Reference Implementation)
>version 1.0
> Java Debug Wire Protocol (Reference Implementation) version
>1.0
> JVM Debug Interface version 1.0
> JVM version 1.2.1 (Solaris VM, build
>Solaris_JDK_1.2.1_04_pre-release, native threads, nojit)
> Launching vm to run runtest
> vm started...
> All threads suspended...
> Error: unable to run runtest..
> Reason: nil.
>
> also a runtest(1) CLI buffer opens
>
>When I continue the program execution the jdebug buffer displays:
>(jde-dbo-command-result 3)
> the runtest(1) buffer displays: Running runtest.
> and the runtest(1) CLI buffer displays (No command specified !!!)
>which my program indicating no command line args have been specified.
>
>If I try to set a braekpoint with the cursor on a program line I get:
> Symbol's function definition is void: line-beginning-position
>
As I said in my previous message, XEmacs does not define this function so
I'll have to find an alternative when I get around to addressing XEmacs
compatibility problems.
- Paul
>If I try step into the program I get: Wrong type argument: sequencep, 1
>
>When I tried continue again I got:
> jdebug buffer:
> (jde-dbo-command-result 3)JDE> 1 4 run
>
>
> JDE> 1 6 break absolute runtest.java 7
>
>
>
>
>
> (jde-dbo-command-result 4)
>
>
>jde/debugger/Application.handleCommand(Ljava/lang/Integer;Ljava/lang/String;
>Ljava/util/List;)V at pc 831: stack height conflict: 0 vs. 1
>
> **Out of memory, exiting**
>
> Process *JDEbug* exited abnormally with code 1
> runtest(1): Running runtest.
> runtest(1) CLI: Process runtest(1) CLI exited abnormally with code
>256
>
>Sorry to be such a bother.
>
>Doug
>-----Original Message-----
>From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
>Sent: Friday, November 12, 1999 4:35 PM
>To: MILLER, DOUGLAS E (SNETCOMM)
>Subject: Re: jdebug problem
>
>
>Hi Doug,
>
>Did you include the jpda lib/sparc directory in your LD_LIBRARY_PATH?
>Failure to do so will result in failure to launch your application, which
>will result in the kind of messages you are seeing. (I have to find some
>way of providing clearer messages.
>
>BTW, I just tried JDEbug with XEmacs 20.4 on Solaris 5.6 without any
>problem except the missing function problem, which I'll fix in the next
>release.
>
>- Paul
