Debugging Failed with Remote Linux

Sysprogs forums Forums VisualGDB Debugging Failed with Remote Linux

This topic contains 10 replies, has 2 voices, and was last updated by  support 1 week, 1 day ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #31444

    Noah
    Participant

    Hello,

    I am having trouble cross-compiling for a custom embedded linux device using a yocto sdk installed on WSL, with VisualGDB running on Windows.
    <h2>My Setup:</h2>
    I’ll break down my setup a bit more:

    Under VisualGDB Project Properties->Project Settings I have:

    • Main build/debug machine set to “Windows 10 Linux Subsystem (Ubuntu)”
    • Checked “Deploy executable on different machine (required to debug with gdbserver)”
      • Deployment Machine: “root@10.0.0.42”
    • The build subsystem is cmake.
      • The CMake toolchain is set using “Specify Yocto Environment File…” where I navigate to the yocto sdk in WSL and select “environment-setup-…….-linux” and leave defaults in the following dialog.

    <h2>What works:</h2>
    Here are is what works:

    I can right-click on the target in the solution explorer and click on “Open SSH Console for 10.0.0.42” and an ssh console will appear.

    I have a simple main.cpp which contains:

    I can generate and compile the project correctly.

    If I SSH into the embedded linux target, I can see the executable that has been placed onto it and I can even run it and view the output of the above test program.
    <h2>The Problem(s):</h2>
    The most prevalent one is that VisualStudio locks up after a clicks and has to be restarted, but I am willing to chalk that up to the other issues I am seeing.
    <h3>Issue #1</h3>
    If I go into solution explorer, and I switch to “Folder View,” then I can navigate to main.cpp in the solution explorer and it will open when I double click on it. It’s path says that it is located at “C:/…./main.cpp” which is what I expect.

    If I switch to “Solution View” or “CMake Targets View” and try to open or edit main.cpp in a similar way, visual studio locks up and has to be closed using task manager.
    <h2>Issue #2</h2>
    If I click “Start” without trying to open up main.cpp, it will configure and build correctly as well as transfer the executable to the target but then I get a message whose screenshot is attached.

    The messages under each tab are as follows:

    GDB Session Tab:

    Exception Details Tab:

    GDBServer Tab:

    Other GDBServer Tab?:

    Thank you for any help! The workflow for this promised by visualgdb would be a great improvement over the current one and there are a few interested parties that may be interested in visualgdb if this works.

    Attachments:
    You must be logged in to view attached files.
    #31449

    support
    Keymaster

    Hi,

    No problem. If Visual Studio locks up, please try obtaining a stack trace as shown here. If it contains VisualGDB  frames, please attach it here along with your VisualGDB build number, and we will investigate further.

    The second issue looks like your gdb executable crashes. Please first make sure you can debug your program manually by running gdb manually on the same machine and with the same gdb you are intending to use with VisualGDB. If you can do that without crashing, we can gladly help you configure VisualGDB to replicate the same setup.

    If the toolchain appears broken and doesn’t work, we can also gladly investigate it your you and build a custom toolchain that will work with your target. Feel free to reach out to our sales if you would like to get a quote on that.

    #31451

    Noah
    Participant

    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

    Attachments:
    You must be logged in to view attached files.
    #31454

    Noah
    Participant

    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.

    • This reply was modified 2 weeks ago by  Noah.
    Attachments:
    You must be logged in to view attached files.
    #31458

    Noah
    Participant

    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.

    • This reply was modified 2 weeks ago by  Noah.
    #31460

    support
    Keymaster

    Thanks for the detailed description. This looks like an issue with the environment variable expansion that was fixed in VisualGDB 5.6.

    The stack trace looks like VisualGDB is trying to read the contents of one of the source files on the remote machine. It could freeze VS if the project contained files called aux.c or com[1-4].c, although VisualGDB 5.6 contains a check for this. Either way, please try updating to the latest Beta (or VisualGDB-5.6.5.4391.msi) and let us know if the problem persists.

    #31462

    Noah
    Participant

    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!

    • This reply was modified 1 week, 6 days ago by  Noah.
    • This reply was modified 1 week, 6 days ago by  Noah.
    • This reply was modified 1 week, 6 days ago by  Noah.
    Attachments:
    You must be logged in to view attached files.
    #31468

    support
    Keymaster

    This could be related to a VS MEF cache bug. Please try restarting Visual Studio. If it doesn’t help, please try right-clicking on the tab header of the source file that is not loading, and select “copy full path”. Please share the full path here, and we will help you get it working.

    #31469

    Noah
    Participant

    Ok, Here is the full path:

    vgdb-lxss:///mnt/c/****/***/****/***/RemoteTest2/RemoteTest2/Source/main.cpp

    Restarting Visual Studio did solve the error, neither did creating a new project.

    #31470

    Noah
    Participant

    Sorry, I typed that restarting Visual Studio “did” solve the error, when I meant to type “didn’t”. So, to be clear, restarting VisualStudio did NOT solve the error.

    Thank you

    #31508

    support
    Keymaster

    Hi,

    Strange. Normally, the WSL projects should use a different type of path mapping and should not allow selecting the incorrect one in the first place. Please double-check that you select the WSL radio button on the target selection page of the wizard, rather than selecting a generic “Build on Linux” option and picking WSL in it. This helps ensure that the correct path mappings are set.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.