Re: debugging with jdb
Len Trigg writes: > Raul Acevedo wrote: > > Would the problem be "solved" if comint returned code 1, instead of 129? > > > > In other words, is the problem that comint returns an inappropriate > > error code, or that comint returns *any* error code at all (i.e. it > > shouldn't get an error from the subprocess in the first place)? > > I think the latter. The bug typically bites me when running JUnit > tests and it's clear (based on the expected output) that either the > process terminates early, or a large part of the output is just lost. > comint is the Emacs interface to external processes such as jdb or bash. It's purpose is to allow Emacs users to interact with external processes, i.e., to send input to the standard input of the external process and to view the standard output of the external process. The JDEE uses comint to allow JDEE users to interact with jdb, the BeanShell, and other external processes. comint writes Emacs user input to the standard input of the external process and reads from the standard output of the external process and displays the output in an Emacs buffer. I don't know how comint handles the error output of an external process. My assumption has always been that it reads the standard error output of the external process and treats it as if it were coming from standard output, i.e., it simply passes the standard output to clients of comint as if the error output were coming from the external process's standard outpuut. My guess is that some recent versions of comint or Emacs have a bug in the handler for the standard error output of an external process that causes the error. Because the JDEE uses comint to interfaces to external processes, in particular, jdb, this would mean that if jdb encounters an error condition and tries to communicate the error by writing a message to its standard error output instead of to its standard output pipe, this causes the 129 error message on some versions of Emacs or Linux. I'm not sure that the JDEE can fix this problem as my suspicion is that the problem is with comint or with Emacs C functions on which comint relies. Paul
Re: debugging with jdb
Raul Acevedo wrote: > Would the problem be "solved" if comint returned code 1, instead of 129? > > In other words, is the problem that comint returns an inappropriate > error code, or that comint returns *any* error code at all (i.e. it > shouldn't get an error from the subprocess in the first place)? I think the latter. The bug typically bites me when running JUnit tests and it's clear (based on the expected output) that either the process terminates early, or a large part of the output is just lost. Cheers, Len.
Re: debugging with jdb
Would the problem be "solved" if comint returned code 1, instead of 129? In other words, is the problem that comint returns an inappropriate error code, or that comint returns *any* error code at all (i.e. it shouldn't get an error from the subprocess in the first place)? Raul On Fri, 2004-10-08 at 12:32 +1300, Len Trigg wrote: > Paul Kinnucan wrote: > > No this is a problem with Comint on some combinations of Emacs and the > > host operating system. I believe it may have something to do with how > > comint handles standard error input from an external process, e.g., > > jdb. > > Yes, I think that's it too. I experience it and posted this bug > report/test case to the XEmacs people: > > http://list-archive.xemacs.org/xemacs-beta/200408/msg00029.html > > (not that anything further has been done about it) > > Cheers, > Len
Re: debugging with jdb
Paul Kinnucan wrote: > No this is a problem with Comint on some combinations of Emacs and the > host operating system. I believe it may have something to do with how > comint handles standard error input from an external process, e.g., > jdb. Yes, I think that's it too. I experience it and posted this bug report/test case to the XEmacs people: http://list-archive.xemacs.org/xemacs-beta/200408/msg00029.html (not that anything further has been done about it) Cheers, Len
Re: debugging with jdb
Raul Acevedo writes: > On Tue, 2004-10-05 at 15:18 -0400, Paul Kinnucan wrote: > > > No this is a problem with Comint on some combinations of Emacs and the > > host operating system. I believe it may have something to do with how > > comint handles standard error input from an external process, e.g., > > jdb. It's my impression that recent versions of Emacs or Linux have > > developed an incompatibility in this area. I cannot fix this problem > > without the active assistance of those who are experiencing it as I do > > not experience the problem on the versions of Emacs, Windows XP, and > > Linux that I use. > > I'm willing to help you figure that out... > > I just tried JDEBug, and that also doesn't work. The JDEBug process > dies mysteriously shortly after I try to attach to a local process, with > no error message on the Emacs side. However the stdout for the Java > process I'm connecting to says "Transport error, error code = -1". I'm > using JDK 1.4.2_05 on Linux. Do you know anything about that? It means that JDEbug cannot attach to the debuggee process for some unspecified reason. One possibility is that the debuggee process was not startedin debug server mode or is expecting to be accessed on a socket other than the one you specified. Paul > > Raul >
Re: debugging with jdb
On Tue, 2004-10-05 at 15:18 -0400, Paul Kinnucan wrote: > No this is a problem with Comint on some combinations of Emacs and the > host operating system. I believe it may have something to do with how > comint handles standard error input from an external process, e.g., > jdb. It's my impression that recent versions of Emacs or Linux have > developed an incompatibility in this area. I cannot fix this problem > without the active assistance of those who are experiencing it as I do > not experience the problem on the versions of Emacs, Windows XP, and > Linux that I use. I'm willing to help you figure that out... I just tried JDEBug, and that also doesn't work. The JDEBug process dies mysteriously shortly after I try to attach to a local process, with no error message on the Emacs side. However the stdout for the Java process I'm connecting to says "Transport error, error code = -1". I'm using JDK 1.4.2_05 on Linux. Do you know anything about that? Raul
debugging with jdb
Raul Acevedo writes: > I haven't debugged with JDE in a while, so I don't know if this is a new > bug with the latest JDEE beta. > > Every time I display an expression with jdb, the debugger exits. Is > this a known issue? It will display the expression just fine, and then > exit with "Comint exited abnormally with code 129". > No this is a problem with Comint on some combinations of Emacs and the host operating system. I believe it may have something to do with how comint handles standard error input from an external process, e.g., jdb. It's my impression that recent versions of Emacs or Linux have developed an incompatibility in this area. I cannot fix this problem without the active assistance of those who are experiencing it as I do not experience the problem on the versions of Emacs, Windows XP, and Linux that I use. Paul
debugging with jdb
I haven't debugged with JDE in a while, so I don't know if this is a new bug with the latest JDEE beta. Every time I display an expression with jdb, the debugger exits. Is this a known issue? It will display the expression just fine, and then exit with "Comint exited abnormally with code 129". Should I use JDEBug instead? I remember there being issues a while back with using JDEBug, have those been resolved? Raul
Re: Debugging with jdb (JDE-2.2.9beta9)
David, Thanks for your hint, I can attach JDE-->JDB to a running process now. What I was doing wrong is that I misunderstood how to attach JDB and kept starting Tomcat under "jdb" rather than "java" using the dt_shmem option. JDE-->JDB then did have nothing to attach to. Thanks, Milan On March 22, 2002 01:36 am: > Milan, > > from Java doc for jdb (Start page=>Tool Documentation=>Basic Tools=>jdb): > > > There are many ways to start a jdb session. The most frequently used way is > to have jdb launch a new Java Virtual Machine (VM) with the > main class of the application to be debugged. This is done by > substituting the command jdb for java in the command line. For example, if > your > application's main class is MyClass, you use the following > command to debug it under JDB: > >% jdb MyClass > > When started this way, jdb invokes a second Java VM with any > specified parameters, loads the specified class, and stops the VM before > executing that class's first instruction. > > Another way to use jdb is by attaching it to a Java VM that is > already running. A VM that is to be debugged with jdb must be started with > the following options: > > option > purpose > -Xdebug > Enables > debugging support in the VM > -Xrunjdwp:transport=dt_socket,server=y,suspend=n > Loads > in-process debugging libraries and specifies the kind > of > connection to be made. > > > For example, the following command will run the MyClass > application, and allow jdb to connect to it at a later time. > >% java -Xdebug > -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n > > You can then attach jdb to the VM with the following commmand: > >% jdb -attach 8000 > > # > > Well in my case it is more complex, because my Application is running on > the remote machine. So I need something like > host:adrres specification. You can find this in the same Docu: > > # > > > Socket Transport > > The JPDA reference implementation provides a socket transport on both > Solaris and Win32 platforms. The socket transport uses standard TCP/IP > sockets to > communicate information between debugger applications and target VM. With > the socket transport, the debugger application and target VM can reside > either on the > same machine or on different machines. The socket transport is identified > through a unique string, dt_socket. This name can be used to select the > socket transport > when invoking the target VM and when selecting a JDI connector. > > In contexts where a client is attaching to a server, socket transport > addresses have the format ":" where is the host name and > is the > socket port number at which it attaches or listens. In contexts where a > server is waiting for a client to attach, the address consists of the port > number alone (the host > name is implicit). > > # > > So, I'm starting the Application with: > java -Xdebug -Xrunjdwp:transport=dt_socket,address=7003,server=y,suspend=n > > > and I've customized the variable jde-db-option-connect-address to > "w001705E:7003" > > In this way I can connect to my application, hit the breakpoints, see the > value of variables. > The only problem is, that with each command I'm getting elisp warning/error > (split-string ...). > > Regards > David Ostrovsky > > > > > > Milan Zimmermann > patico.ca> Kopie: > Thema: Re: Debugging with > jdb (JDE-2.2.9beta9) 22.03.02 06:22 > > > > > > > How are you starting the process you are attaching to from jdb? the reason > I > ask is that you are further that I - I cannot even attach jdb to a running > process - thanks. > > On March 19, 2002 06:46 am, you wrote: > > After activating the debugger (I can connect, set breakpoints etc) > > I'm getting error/warninig with each action. The action is executed. > > > > Backtrace: >
Re: Debugging with jdb (newbie)
> I have set up jdb as my debugger and source directories for > debugger to '/dziela/java'. Appending slash to the path name helped. J.K.
Debugging with jdb (newbie)
I'm trying to debug with jdb and something goes wrong with source tracking. I've created a simple one file project in /dziela/java consisting of of one class in foo.java. Whenever I start debugging, debugger hits at the first line of foo.main, but it tries to show the contents of ... javafoo.java. Here is what I see in my xemacs: buffer *buffer list*: MR Buffer Size Mode File -- -- . javafoo.java0 JDE /dziela/javafoo.java <- ??? *% *debugfoo*271 Debugger * *jde-log*1698 Fundamental foo.java 175 JDE /dziela/java/foo.java *scratch* 197 Lisp Interaction * "*Buffer List*"327 Fundamental buffer *debugfoo*: cd /dziela/java/ jdb -classic foo Initializing jdb... > Deferring breakpoint foo.main. It will be set after the class is loaded. > run foo > VM Started: Set deferred breakpoint foo.main Breakpoint hit: thread="main", foo.main(), line=6, bci=0 6 int i = 1; main[1] buffer javafoo.java: empty, contains just '=>' sign I have set up jdb as my debugger and source directories for debugger to '/dziela/java'. What is wrong ? My config: RedHat 7.1 jdk1.3.1_01 elib-1.0 eieio-0.16 jde-2.2.8 semantic-1.4beta5 speedbar-0.13a xemacs-21.1.14 J.K.
