First "-var create" call takes too much time

[elikfir]

Hi,

lately when I debug with visualGDB the first watch with var create takes too much time

see the image

can you please help me with that?

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This message means that your gdb debugger is taking too long to process the variable evaluation command issued by VisualGDB. The delay does not come from the VisualGDB side and it caused by the gdb itself.

If you would like to find out what is causing it, please consider building a debug version of your gdb executable and stepping through it once you reproduce the issue.

[elikfir]

I tried to reproduce the issue outside the visualGDB and it works fine. I actually run every command that VisualGDB sent.

[elikfir]

ok, Now I’m able to reproduce the issue without visualGDB.

thanks

[support]

Good to know you managed to reproduce it. One thing, issues like this could be caused by bugs in the network stack (packet with the command from VisualGDB gets lost and is never resent). If the issue happens intermittently over SSH, but never locally (e.g. in an xterm window), it could be caused by the network rather than the gdb executable.

[elikfir]

thanks,

I use Windows with WSL2, so I don’t know if it’s related or not.

this raised another issue I have – I didn’t managed to connect to WSL Ubuntu20.04 by VisualGDB (it stuck while trying to connect). In order to connect I have to run sshd on the Ubuntu side and on VisualGDB I use SSH stack instead of other connection to WSL (I don’t know what’s it).

this bother me because the IP has changed after every reboot and I need to update the local DNS (system32\drivers\etc\hosts) with the new IP. do you have any clue why is that?

[support]

Hi,

Normally, WSL2 should work out-of-the-box, as long as the Linux side can connect to the Windows side via TCP/IP. Please see this page for a detailed instructions on troubleshooting WSL2 issues.

[elikfir]

I tried to use this page and it doesn’t help.

I debug the LinuxAppLauncher and it looks like the issue is that WSL doesn’t allow it to connect via port 64526, and it stuck. when use port 139 which open to TCP protocol it finish the execution of this app with:

Launching docker, pty=0…
argv[0] = …
argv[1] = …
…

DISPLAY = :10
Waiting for the target process PID…
Target process PID: 6718
Forwarding output…
Mismatching initialization packet (size=-1, type=81, payload=0)
Reporting exit code (0)

I’m using Win11. The IP address is correct.

I don’t know if it’s OK, but if yes, how can I configure VisualGDB to use different port than 64526? (forcing the app to use this port doesn’t help)

Or maybe, how can I allow windows to let this APP to listen on this port? firewall changes doesn’t help.

thanks

[support]

Thanks for checking it. VisualGDB simply opens the TCP listener at the first available port, and then tells the WSL launcher to connect to it. You can try testing it out with the following C# code on the Windows side:

TcpListener listener = new TcpListener(0);
listener.Start();
int tcpPort = (listener.LocalEndpoint as System.Net.IPEndPoint).Port;
listener.AcceptSocket();

If you cannot telnet to the port reported by IPEndPoint from WSL, please try finding out which ports work, and looking for settings that could be affecting the broken port ranges.

[Author]

Posts