Sysprogs forums › Forums › VisualGDB › First "-var create" call takes too much time
This topic contains 8 replies, has 2 voices, and was last updated by support 1 year ago.
May 24, 2022 at 15:07 #32681
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.May 24, 2022 at 15:11 #32683
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.May 24, 2022 at 15:13 #32684
I tried to reproduce the issue outside the visualGDB and it works fine. I actually run every command that VisualGDB sent.May 24, 2022 at 15:51 #32685
ok, Now I’m able to reproduce the issue without visualGDB.
thanksMay 25, 2022 at 08:02 #32692
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.May 25, 2022 at 11:29 #32695
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?May 27, 2022 at 13:52 #32702
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.May 31, 2022 at 03:17 #32720
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 = …
argv = …
DISPLAY = :10
Waiting for the target process PID…
Target process PID: 6718
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.
thanksMay 31, 2022 at 07:45 #32721
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:C++1234TcpListener 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.
You must be logged in to reply to this topic.