Forum Replies Created
-
Posts
-
Ok, I updated to the beta you recommended.
If I set up the project to “Store files on localhost-lxss and access them over the network (recommended)”, then VisualStudio/VisualGDB does not load the contents of the file in the editor when I try to open it (see attached image). Since this process should be independent of the actual debug target, I believe VisualGDB may still be the culprit here. That being said, it does not lock up anymore.
However, if I set up the project and use “Setup shared mount point manually”, then everything seems to work.
Thank you!
If it helps, when I go into “Advanced GDB Settings”->”Diagnostics” and check “Save all low-level interaction with GDB to ******Test.log, the only line in that file after the gdb error is:
${GDB} --interpreter mi --args "/mnt/c/Users/nmeltzer/<path to target>/*********Test"Which I can paste into WSL and it runs without issue. So this appears to be a VisualGDB bug.
I was able to debug the target over the command line by running
gdbserver localhost:8000 tmp/on the target embedded linux device and
$GDB [pathto]/on WSL. Doing this, I was able to set a breakpoint at main, and continue. The program would then break properly at main.
However, VisualGDB still fails to debug or set breakpoints. It appears VisualGDB is executing similar commands to those above, using the same GDB and GDBServer that I am running manually on the command line. Attached are screenshots of the VisualGDB diagnostic window, and of the manually-debugged target on the command line.
Thank you again for the help, I hope this thread is useful to others who are experiencing similar issues.
Ok thanks, I’ll verify gdb is running correctly aside from VisualGDB.
In the meantime, I also generated a call stack trace that shows the lockup error I described (see attached file). I am using VisualGDB version 5.5R5 (build 4124) with visual studio 2019 version 16.11.3. Hope this helps
