VisualGDB exception when selecting Toolchain

Sysprogs forums Forums VisualGDB VisualGDB exception when selecting Toolchain

This topic contains 11 replies, has 2 voices, and was last updated by  support 11 hours, 48 minutes ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #31777

    Hello,

    we have Linux Buildserver running to crosscompile an application for an arm Target. This works quite well in our testing facility with direct access to the server. To be able to build and deploy the application localy on my development-pc (sometimes this is needed when we are working off-site) I installed Unbuntu inside WSL2 (with the appropriate crooscompiling toolchain) and activated sshd for access. Building applications on console works fine. Unfortionately I can not get this running in Visual Studio / VisualGDB. It fails when trying to selct the toolchain:

    • Selecting “Specify toolchain manualy by locating GDB executable” shows Ubuntu Filesystem -> GDB-executable can be selected
    • New window “Edit Toolchain” opens -> Pathes are set properly
    • Hitting “Apply” or “Ok” in the property window throws exception:

    VisualGDB version: 5.6.101.4461
    ------------------ System.NullReferenceException ------------------
    System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    bei VisualGDB.Common_GUI.WPF.Property_pages.MSBuildSettingsPage.ControllerImpl.ExportSettings(Object settingsObject, mx2 ectx)
    bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.c2.j.Export(qh3 b, VisualGDBProjectSettings2 a)
    bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.r1(c2 b, l a)
    bei VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.m(Boolean b, tw a, String d, Action c)
    bei VisualGDB.Common_GUI.WPF.ProjectPropertiesWindow3.Apply_Click(Object sender, RoutedEventArgs e)
    trace=[VisualGDB.Common_GUI.WPF.Property_pages.MSBuildSettingsPage+ControllerImpl.ExportSettings:4078, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel+c2+j.Export:37, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.r1:32, VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.m:119, VisualGDB.Common_GUI.WPF.ProjectPropertiesWindow3.Apply_Click:0]

    Any ideas what’s going wrong?

    Thanks

    Nils

    #31778

    support
    Keymaster

    Hi,

    This looks like VisualGDB could not get fully activated on that computer. Could you please double-check the Help->About VisualGDB window? Does it show the correct activation information? If yes, does opening the About window before editing any settings solve the problem?

    #31783

    Hello,

     

    thank you for your quick response. Please find Screenshots of the “About” dialog and the configuration process enclosed (I actually do not know how to insert an image directly into the post… What do I have to enter as “Source” when using “Insert->Image”?)

    Even after opening the “About dialog” the settings are not stored…

     

    Best regards

    Nils

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

    support
    Keymaster

    Thanks for the screenshots. Indeed, the license looks properly loaded and should not be causing this. Could you please double-check whether the problem also happens for other projects, or if it’s specific to this one? Some manual edits to .vgdbsettings and .vcxproj files could cause hard-to-track internal errors.

    You can also try using this build: VisualGDB-5.6.101.4492.msi. Please try enabling View->Other Windows->VisualGDB Diagnostics Console before changing the settings, and share the contents of the diagnostics console along with the new error message.

    #31831

    Hello,

     

    I did some more tests as suggested. Unfortunately without success. Please take a look at the attachment.

     

    Thanks!

    Best regards

    Nils Ossenbrink

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

    support
    Keymaster

    Thanks, it looks like the problem is somewhere in the logic that writes the new toolchain ID to the project configuration. Please try this build: VisualGDB-5.6.102.4507.msi

    It generates much more diagnostic output in that part, so it should help us narrow it down further. Please try attaching an updated log from the diagnostic console (no screenshots/other logs are necessary) and we will try find the root cause.

    #31852

    Hello,

    logs attached…

     

    Best Regards

    Nils

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

    support
    Keymaster

    Thanks, we have narrowed it down further and updated VisualGDB to show a more informative error message. Please try this build: VisualGDB-5.6.102.4508.msi

    If the problem persists, please try following the steps below:

    1. Enable VisuaGDB Diagnostics Console
    2. Open VisualGDB Project Properties and re-import the toolchain. This should be done with the diagnostic console enabled.
    3. Make sure the imported toolchain is selected in the VisualGDB Project Properties window. If it shows “no toolchain selected”, please try selecting it manually.
    4. If the toolchain doesn’t appear in the list, or if selecting it doesn’t work, please attach the updated diagnostic log. If selecting the toolchain manually solved the problem, feel free to attach a screenshot of the toolchain list and the diagnostic log as well, so that we could check why the automatic selection didn’t happen.
    #31862

    Hello,

     

    the problem is that the imported Toolchain does not show up. Only the default Toolchains are available even after importing…

     

     

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

    support
    Keymaster

    Thanks for the updated log file. Indeed, VisualGDB is saving the imported toolchain to the location normally used for the Windows toolchains:

    This happens because the project is configured to connect to localhost via the default SSH port, so VisualGDB treats it as a Linux machine name. In order to workaround it, please consider using “127.0.0.1” instead of “localhost”, or specifying the port explicitly, i.e. “localhost:22”.

    That said, we normally advise picking the WSL distro directly in the host selector, rather than using SSH. It will enable the special WSL-specific communication mode, that is faster then SSH.

    #31868

    Hello,

     

    using the IP instead of “localhost” seems to work. I will do some more tests and come back with a feedback later. Thank you very much for your support!

    Best Regards

    Nils

    #31871

    support
    Keymaster

    No problem and good to know it works. We have also updated VisualGDB on our side to suggest the use of the IP address or port when trying to create an SSH connection to ‘localhost’.

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

You must be logged in to reply to this topic.