[
https://issues.apache.org/jira/browse/NETBEANS-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470142#comment-17470142
]
Joao Graca da Nobrega commented on NETBEANS-5949:
-------------------------------------------------
Hi Pat,
There is no other program using the ip port to be used by the debugger. Also
notice that every time you run the program a different port is used... The
issue seems to be related to the tunnel used to connect to the application. In
the remote-platform-impl.xml file we can see
<sshsession host="${remote.platform.host}"
port="${remote.platform.port}" username="${remote.platform.user}"
password="${remote.platform.password}" trust="true">
*<remotetunnel lport="${jpda.port}" lhost="localhost"
rport="${jpda.port}"/>*
This is a smart way for the debugger to connect to the application. First the
remote java application only allows debug connections from the local machine
(notice the address 127.0.0.1:53738 on your example). This is much better from
the security point of view. Second the actual connection to the process being
debugged goes through a tunnel created inside the SSH channel. The issue here
is that the remotetunnel itself is using that same port, hence we get the
"address already in use" error. If we comment the remotetunnel config, the
error is gone but, of course, netbeans fails to connect to the application to
debug it.
Additionally using remotetunnel instead of localtunnel seems to be an
implementation problem. If we are not mistaken NetBeans connects to the
application it wants to debug, and not the other way around. Now, what an ssh
remote tunnel allows us to do is:
"allows anyone on the remote server to connect to TCP port X on the remote
server. The connection will then be tunneled back to the client host, and the
client then makes a TCP connection to port Y on {{{}localhost{}}}. Any other
host name or IP address could be used instead of {{localhost}} to specify the
host to connect to."
[https://ant.apache.org/manual/Tasks/sshsession.html#RemoteTunnel]
[https://www.ssh.com/academy/ssh/tunneling/example#remote-forwarding]
We tried using a localtunnel instead but we have a similar problem:
com.jcraft.jsch.JSchException: PortForwardingL: local port 127.0.0.1:53601
cannot be bound.
[...]
Caused by: java.net.BindException: Address already in use: bind
at java.base/sun.nio.ch.Net.bind0(Native Method)
[...]
We don't understand how you don't have the same issue. Can you confirm that the
following in your "remote-platform-impl.xml" file is as follows:
<target name="-debug-remote-passwd" depends="init, jar,
-init-remote-platform-properties, -copy-to-remote-platform, -ask-password,
-debug-start-debugger" if="remote.platform.auth.passwd">
<addressport address="${jpda.address}" property="jpda.port"/>
<sshsession host="${remote.platform.host}"
port="${remote.platform.port}" username="${remote.platform.user}"
password="${remote.platform.password}" trust="true">
<remotetunnel lport="${jpda.port}" lhost="localhost"
rport="${jpda.port}"/>
<sequential>
<remote:runwithpasswd additionaljvmargs="${debug-args-line}
-Xrunjdwp:transport=${debug-transport},address=${jpda.address}"/>
</sequential>
</sshsession>
</target>
> remote debugger does not work
> ------------------------------
>
> Key: NETBEANS-5949
> URL: https://issues.apache.org/jira/browse/NETBEANS-5949
> Project: NetBeans
> Issue Type: Bug
> Components: debugger - Java, projects - Ant
> Affects Versions: 12.4
> Environment: Host is Windows 10, Netbeans 12.4
> Remote Host is raspberry pi with java 11.0.12.
> Reporter: pat
> Priority: Major
>
> Create a java application project.
> Add this code to main and fix the imports
> public static void main(String[] args) {
> try {
> InetAddress id = InetAddress.getLocalHost();
> System.out.println(id.getHostName());
> System.out.println("java version is " +
> System.getProperty("java.version"));
> System.out.println("VM is " +
>
> ManagementFactory.getRuntimeMXBean().getVmVersion());
> } catch (UnknownHostException ex) {
> Logger.getLogger(HelloWorld.class.getName()).log(Level.SEVERE,
> null, ex);
> }
> }
> Run natively to verify you got it right.
> Follow the instructions here to create a remote java standard edition
> platform targeting a different Linux computer. My computer is a raspberry
> pi with java 11 installed, Oracle Java SE 8 Embedded is no longer available
> for most people but java 11 works fine. (The bug is independent of java
> version on the target).
> https://netbeans.apache.org/kb/docs/java/javase-embedded.html?print=yes
> Select the remote platform you created and run the program. The output
> should show that it ran on the remote host.
> Now debug the program. I get the following error.
> ant -f C:\\Users\\PATGI\\OneDrive\\Documents\\NetBeansProjects\\HelloWorld
> -Dnb.internal.action.name=debug -Dremote.platform.passphrase=*****
> -Dremote.platform.rp.target=linuxarm-15
> -Dremote.platform.rp.filename=linuxarm -Ddebug.class=helloworld.HelloWorld
> -Dremote.platform.java.spec.ver=11 debug-remote
> init:
> deps-jar:
> Updating property file:
> C:\Users\PATGI\OneDrive\Documents\NetBeansProjects\HelloWorld\build\built-jar.properties
> compile:
> Copying 1 file to
> C:\Users\PATGI\OneDrive\Documents\NetBeansProjects\HelloWorld\build
> Nothing to copy.
> To run this application from the command line without Ant, try:
> java -jar
> "C:\Users\PATGI\OneDrive\Documents\NetBeansProjects\HelloWorld\dist\HelloWorld.jar"
> deploy:
> jar:
> C:\Users\PATGI\OneDrive\Documents\NetBeansProjects\HelloWorld\nbproject\remote-platform-impl.xml:143:
> Unable to create javax script engine for javascript
> BUILD FAILED (total time: 0 seconds)
> I was able to for the debugger to work by manually starting the debugger on
> the remote host with something like
> /usr/bin/java
> -agentlib:jdwp=transport=dt_socket,address=*:8000,suspend=y,server=y
> -Dfile.encoding=UTF-8 -jar
> /home/pi/NetBeansProjects/HelloWorld/dist/HelloWorld.jar
> And then connect the debugger to a process already running on the remote host
> at port 8000.
> I traced this back to javascript not being supported in this installation of
> Ant. I also think several of the configuration variables for remote
> debugging are not setup. e.g. jdpa.address and jdpa.port but I could easily
> be wrong about this.
> The good news is it can be made to work and it is very nice when it is
> working.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
