I have not been able to get remote debugging working with my standalone web app. Currently I am rsync-ing changes whenever I build and outputting a lot to the log. I would like to use the debugger. The app cannot be run on a VM, or locally, it has to be run on the actual deployment machine due to licensing restrictions with the database, and also due to it’s network location.
I just spent about and hour and a half trying to get remote debugging working via SSH tunneling - I feel very close - but can’t get the last piece.
I can get the remote console debugger running on the server.
I can make a tunnel over port 44553 via ssh. [ssh -L 44553:localhost: 44553 root@myserver]
I can make a tunnel over port 13897 via ssh (necessary?) (Tried Local and Remote).
Xojo will connect to the stub.
Xojo will transfer the app and unzip it.
Xojo will execute the app!
But it terminates with “Can’t locate target IDE For Debugging”.
I have read that debugging attempts to connect back to the IDE. Does it do it over port 44553 or 13897?
Is there a different port or different connection involved?
Anyone who has had success in doing this over SSH, or some another readily available VPN method, please let me know how you do it.
I want the app to execute on the remote server, over the internet, using the debugger, if possible.
FWIW the app, when you compile it, bakes in the address of the machine with the IDE running
But it will use a different port to connect back
You may need a second ssh tunnel for the communications back to the IDE as it wont be on the same port
Give me a minute to see what port it uses
looks like the built app connects back to the IDE over 13897
the thing that may get messed up here is that the IP of the machine the IDE is on gets baked in to the app yet the tunnels will make it seem like the ports are local connections
not sure how that might impact things
Thanks Normal - that was what I needed. I got it working! (I am actually kinda shocked)
It took two ssh tunnels and IP redirection but it seems to work great honestly, once you have the whole thing up. The piece that I needed was the info about the baked in IP which made it clear I needed the IP redirection. I just didn’t even think about that. So thank you for your help! I am thinking of writing a tutorial about this since it is a bit tricky and I bet others would be interested.
Norm is saying that the remote debug version of the app has hard-coded or “baked in” the IP address of the machine with the IDE that builds the app. That is how the remote version finds the IDE so it can communicate back to it. Instead of passing the IP somehow like a command line parameter the IP address is built into the executable.
That is probably one of the biggest reasons remote debugging has to be done on the same LAN. So that the IP address will work from the remote machine. If you send the debug build to a machine that is NOT on your own lan then you have to figure out how to route back the requests to the IDE.
Hope this makes sense.
So you have a couple of issues debugging over the internet:
firewalls
IP address routing
Tunnels can take care of #1
IP forwarding can take care of #2
If you can use a VPN (not always possible) it should take care of BOTH issues for the most part.
So, who does the backing. The Xojo developer in his/her code, or is it how Xojo compiles debug information into the “object” code. I guess its the latter, with debug code picking up the IP address of the machine on which the compiling was done …
As far as I understand it, yes you are correct. The IP is coded into the debug app by the IDE at the time of compiling. I don’t believe there is any user control over it - although that would make a helpful feature.
@Norman Palardy - is there a reason that the debug ports of the IDE and the ports and IP address in the debug app are not user-configurable at build time? It would at least give flexibility for people who are running into firewall issues or routing issues. Thoughts?