First time here? Check out the FAQ!
1

Remote debug X11 forwarding problem

  • retag add tags

Hello,

I'm running Wing IDE Pro on Windows machine and trying to debug remotely on the Linux machine (Ubuntu 21.04).

I've set up a remote debugging environment using ssh with X11 forwarding. Debugging works well but I cannot see any plots (matplotlib, seaborn, etc.), which I suspect X11 forwarding is not working. However, there's no error message so I'm stuck on how I should proceed. I'm running Xming server on the Windows machine.

For example, if run this minimal code in Debug Console (in debug mode):

from matplotlib import pyplot as plt
plt.plot([1,2])
plt.show()

it returns the following:

[<matplotlib.lines.Line2D object at 0x7f9f4fdacb80>]

but no plot windows are visible to me.

To compare, I installed a Wing IDE package on the Linux machine and when I remote execute Wing IDE using ssh (Bitvise), I can see the plots correctly. This means my X server is running correctly and my ssh agent is capable of forwarding X11 packets.

So it seems when I do the remote debugging from within my local machine's Wing IDE, X11 packets are not forwarded. FYI, here's my ssh client config file:

Host testserver
    HostName 10.0.0.1
    User tester
    IdentityFile C:\Users\tester\.ssh\tester-key
    ForwardX11 yes
    ForwardX11Trusted yes

What am I missing here?

dbdq's avatar
46
dbdq
asked 2021-06-29 09:13:19 -0600, updated 2021-06-29 09:15:00 -0600
edit flag offensive 0 remove flag close merge delete

Comments

Can you run an X11 app that connects back to your Windows system outside of Wing? The ssh program is what sets up X11 forwarding (Wing just specifies a command line option to enable it) and it's possible that some configuration is required on Windows.

Wingware Support's avatar Wingware Support (2021-06-29 09:28:38 -0600) edit

You were right. The ssh setting on my client side was the problem. I was using Bitvise to execute an app remotely which worked because it was a separate setting from the default OpenSSH in Windows and I believed the setting was correct. I fixed it by adding an environment variable as DISPLAY=localhost:0 on the Windows client side.

dbdq's avatar dbdq (2021-06-30 02:26:13 -0600) edit
add a comment see more comments

1 Answer

1

I fixed by adding an environment variable on the Windows client machine as:

DISPLAY=localhost:0
dbdq's avatar
46
dbdq
answered 2021-06-30 02:27:08 -0600
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer