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
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
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
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
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
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
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
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 (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.
