• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem with simple remote debug testcase  RSS feed

 
Jim J Anderson
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I use Eclipse for debugging. My real problem is that I would like to debug the server side java code of a web application that is running in Tomcat. I have been trying for a week or more to get that to work, but without success. But that is on hold because I saw that the tomcat Catalina log file is showing errors when I specify debug JVM options.

Before tackling that problem, I decided to create a simple test case that I can run on a remote server and then connect Eclipse from my local host to the remote server. I wrote a simple test class, 'StuckLoop.java', which runs just fine when I start it without debugging. However, when I try to run the test class so that it can be debugged, the jvm will not start and gives the following error message:

ERROR: transport error 202: recv failed during handshake: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
Abort


Here is my test class:



I run:

$JAVA_HOME/bin/javac StuckLoop.java

and then:

$JAVA_HOME/bin/java StuckLoop

where $JAVA_HOME is: /usr/share/java8/jdk1.8.0_20 and the program runs ok.

If I run:

$JAVA_HOME/bin/java -agentlib:jdwp=transport=dt_socket,address=8787,server=n,suspend=n,timeout=10 StuckLoop

then I get the error messages shown above. Note, that the command line options are those that I picked up off the internet. I have done a reasonable about of reading, and it looks like these options should work, but I am no expert and I'm looking to find out if my command line is formed correctly or if there are possible problems causing me error.

My first question is whether anyone else gets the same results that I do?

Assuming, the answer to my first question is yes, my second question is why does it fail and what can I do to fix it?

Jim A.


 
Gamini Sirisena
Ranch Hand
Posts: 378
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
works for me.. with eclipse and the class added to a package..

You seem to be getting a Connection refused

May be it's a firewall?
 
Jim J Anderson
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Gamini

Thanks for the suggestion, but I am running this on an internal network and there is not firewall between the machines.

I am running on an old o/s that needs to be upgraded. I'm going to upgrade and see what happens. I will try running it on another PC too.

Jim
 
Jim J Anderson
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

OK, I got my test case working with my debugger (Eclipse). I wanted to document what worked and document why my test case was not working.

First what worked, assuming that I am starting with my test case, 'StuckLoop.java', and that it has been compiled with the javac debug option, '-g'.

1) Import the source code for the test case so that is viewable with the debugger. Set a break point at line 10 of the example.

2) Create a run configuration in the debugger. In Eclipse, this means select 'Run --> Debug Configurations' and filling out the form that pops up.
The entries that I used were:
name: stuck (the name could be anything)
project: stuckProject (the name could be anything)
Connection type: Standard (Socket Listen)
Connection Properties:
Port: 8787
Allow termination of remote VM (I left this unchecked)

3) After the information in step 2 is entered, click on the 'Debug' button. If you are in the Eclipse debug perspective, the upper left panel will
display that a thread has started and it will show that it is in the wait state (waiting for the remote JVM on port 8787).

4) Run the StuckLoop class with the following command:

/usr/share/java8/jdk1.8.0_20/bin/java -agentlib:jdwp=transport=dt_socket,address=8787,server=n,suspend=n,timeout=10 my.example.StuckLoop


NOTE: The above line assumes that StuckLoop.java has a package statement showing StuckLoop is in the 'my.example' package. This is package statement
is not included in the example provided.

Taking these steps, I was able to run the command in step 4 and the debugger stopped the program at the right place. It took a bit of time, maybe a minute or two,
to hit the break point since bebuggers are generally slow.


Why was my test case not working originally?

Well, I skipped step 3 and received the error message shown in my original post. My expectation was that when I ran the command, the program would run and
make a connection with the debugger when the debugger thread became available. That is how I would have implemented the connection, if I had written the
code, but it is what it is. I was confused by the message 'connection refused', which was not the case at all. The error message should have said 'debugger connector is
not available'.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!