VisualGDB: Error: Bash process exited before connecting to output port

[helpme]

I installed the latest Ubuntu and OpenSuse WSL images through the Windows Store and I’m running Windows 10 build 16299.

C:\>wslconfig /l
Windows Subsystem for Linux Distributions:
Ubuntu (Default)
Legacy
openSUSE-42

The issue is that I am unable to connect to the new WSL images with VisualGDB.  Now I always get the error:  VisualGDB: Error: Bash process exited before connecting to output port

I am able to use putty to connect to the ssh port on the new Ubuntu WSL image, but not with VisualGDB.  Has anybody tested using VisualGDB with multiple WSL installations?

Thanks.

[support]

Hi,

VisualGDB would normally use the HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss\DefaultDistribution registry key to locate the LXSS distro to use. Could you please check that the value points to a valid LXSS installation on your machine? If you are not sure, please feel free to attach a screenshot of that registry key contents (or a .reg file).

As another quick workaround please try creating another regular SSH connection and simply specify localhost:<port number> in the “Host name” field, so that VisualGDB will use SSH.

[helpme]

The registry key points at the appropriate version of WSL.  Please test an updated WSL image from the Windows Store when running the Windows Fall Creator’s Update (<span class=”ng-isolate-scope”><span class=”ng-scope”>Windows 10, version 1709</span></span>).  This appears to have issues.

VisualGDB was able to access the WSL through localhost:portnumber, but that may not be ideal for multiple developer machines with different sshd configs.

 

1>System.Reflection.TargetInvocationException
1>System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Exception: Bash process exited before connecting to output port
1>   at ju1.r.f1(CommandLineAction b, CommandFlags a, Boolean c)
1>   at ju1.r..ctor(CommandLineAction d, CommandFlags b, d41 a, Boolean c)
1>   at ju1.h_4(d41 b, String a, String c, String e, ExpandedEnvironment f, CommandFlags d)
1>   at ym1.k1(String e, String d, String g, ModifiedEnvirionment c, o9 f, Int32 a, CommandFlags b)
1>   at m21.g(String b, String a)
1>   at q22.i(BuildMode a, f b)
1>   at q22.h(BuildMode a)
1>   at cn1.b(String b, BuildMode c, e a)
1>   at VisualGDB.MSBuild.BuildHelper.LaunchBuildAction(String action, String settingsFile, String generatedMakefile, String targetPath, String cancelEventName, IBuildCallbacks callbacks, Boolean suppressErrorParsing)
1>   at Sysprogs.build.tasks.shared.LaunchVisualGDB.<>c__DisplayClass21_0.<Execute>b__0()
1>   — End of inner exception stack trace —
1>   at Sysprogs.build.tasks.shared.LaunchVisualGDB.Execute()
1>—Inner exception—
1>System.Exception: Bash process exited before connecting to output port
1>   at ju1.r.f1(CommandLineAction b, CommandFlags a, Boolean c)
1>   at ju1.r..ctor(CommandLineAction d, CommandFlags b, d41 a, Boolean c)
1>   at ju1.h_4(d41 b, String a, String c, String e, ExpandedEnvironment f, CommandFlags d)
1>   at ym1.k1(String e, String d, String g, ModifiedEnvirionment c, o9 f, Int32 a, CommandFlags b)
1>   at m21.g(String b, String a)
1>   at q22.i(BuildMode a, f b)
1>   at q22.h(BuildMode a)
1>   at cn1.b(String b, BuildMode c, e a)
1>   at VisualGDB.MSBuild.BuildHelper.LaunchBuildAction(String action, String settingsFile, String generatedMakefile, String targetPath, String cancelEventName, IBuildCallbacks callbacks, Boolean suppressErrorParsing)
1>   at Sysprogs.build.tasks.shared.LaunchVisualGDB.<>c__DisplayClass21_0.<Execute>b__0()
1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\remote.targets(15,2): error : Exception has been thrown by the target of an invocation.

[support]

Hi,

Strange. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2024.msi

It will show the command line it is trying to run as a part of the exception message. Please try running the same command line manually and see if it shows any meaningful errors.

[helpme]

The latest installer worked, but I lost the visualgdb properties menu within visual studio.  I’ve tried reinstalling and repairing to no avail.  Any ideas how to get this back?

Installing the latest visualgdb appeared to work with the new WSL image, but there appears to be another issue.  I have Ubuntu and OpenSuse wsl images installed.  Ubuntu is set as the default as shown by wslconfig and by checking the registry.  When compiling it appears to use the Ubuntu image for most of the work, but I also noticed this within the output:

1>C:\Users\me\AppData\Local\Packages\46932SUSE.openSUSELeap42.2_022rs5jcyhyac\LocalState\rootfs\usr\include\c++\5\bits\c++0x_warning.h(32,2): error : …

Note that it is referencing the OpenSUSE image, not the Ubuntu.  If I had to guess, the openSUSE BasePath is being used as that guid shows up first alphabetically within the registry:

openSUSE: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{3106b4e7-c41e-4509-a3b9-195bc72b945b}

Ubuntu:      HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{3c61b403-dbbb-405f-991a-ef51079d0207}

Would you please test multiple WSL installs?  It seems there are quite a few issues.

[support]

Hi,

The LXSS root directory is currently cached until you restart Visual Studio, so if you changed the default key after starting VS, it could get an invalid value.

With VisualGDB menus, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2037.msi

We will try to provide better support for multiple LXSS installations in v5.4, but we can still help you resolve the issues you encounter currently. If you can still confirm inconsistent behavior with WSL paths, we can send you another diagnostic build with further logging that will help pinpoint this.

[helpme]

The wsl default was never set to opensuse, so I don’t think that was the reason visualgdb was using the Ubuntu and openSUSE paths at the same time.  I would guess that is a real bug that needs to be tested.

[support]

Hi,

No problem, we will test this as a part of the v5.4 release cycle and post an update here once it is fully tested and supported.

[helpme]

There is something wrong with how the toolchain is configured.  I setup a vagrant centos image, and visualgdb uses the vagrant gcc, but somehow the Ubuntu WSL ld.  That is pretty scary that visualgdb is combining the tools from Vagrant and WSL.

[support]

Hi,

Strange, this should normally not happen. We can definitely investigate this if you could let us know the steps to reproduce it, or share the project files demonstrating the problem.

[helpme]

To reproduce:

Install Windows Fall Creator Edition.

Use the Windows Store to install Ubuntu and opensuse.

Compile a test project and review the header usage to see the issue.

 

[helpme]

To reproduce, you also need to switch between the WSL configurations and compile.  You can do this with the wslconfig command.

Something must be getting cached and not updated in appdata\VisualGDB, because as soon as I deleted this directory the existing issue went away.

[rkeithhill]

I fixed this by noticing that my original (Legacy) Bash install had this file /tmp/LinuxAppLauncher-v2 while my new default Ubuntu did not. I started the Legacy bash, copied the launcher file to my C drive.  Then started the Ubuntu bash and copied that file from the C drive to the /tmp dir.  Then debugging started working.

[Author]

Posts