VisualGDB exception when selecting Toolchain

[nils.ossenbrink@beumer.com]

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

[support]

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?

[nils.ossenbrink@beumer.com]

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.

[support]

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.

[nils.ossenbrink@beumer.com]

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.

[support]

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.

[nils.ossenbrink@beumer.com]

Hello,

logs attached…

 

Best Regards

Nils

Attachments:

You must be logged in to view attached files.

[support]

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.

[nils.ossenbrink@beumer.com]

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.

[support]

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

Saving newly imported toolchain to C:\Users\709218\AppData\Local\VisualGDB\ToolchainProfiles\localhost\com.sysprogs.imported.arm-linux-gnueabihf-4.8.3__r0...

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.

[nils.ossenbrink@beumer.com]

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

[support]

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’.

[Author]

Posts