Terminal just closes on bunch of output

[TimoRoth]

After I updated to 3.0.1 today, from I think 3.0.0, the moment I connect to a server via ssh and then do a "git pull" in a directory there, the terminal window just closes.

Even if I do it in a screen, and then later reconnect to that screen, that also closes the terminal.

I can't see any errors anywhere, just an immediate close of the terminal window.

After downgrading back to 3.0.0 the issue is gone.

[McG800]

I'm also having this issue with 3.0.1 when performing a long listing of files in a directory. The terminal just closes. There are 132 lines in the listing.

Downgrading back to 3.0.0 does allow me to do that long listing.

[TimoRoth]

So I guess it's more like a certain character, or just large amounts of output in short time, that break it. Can't really figure out a proper way to debug this, and I'm not setup to be able to bisect between 3.0.0 and 3.0.1.

[jwalsh2me]

I have the same issue after upgrading to 3.0.1 with git pull. I also tried to edit in VIM and when I went to do an insert it closed. Not a big file at all, it was the .zshrc.

[mintty]

Also please provide a reproducible test case. In this case, it would be a terminal log (option --log=file, can be added to the shortcut, use an absolute Windows path name to be sure to find the log file).

[mintty]

On long file listing, I'm getting
wslbridge error: connection broken.
If I refrain from static linking of wslbridge-backend, it does not occur.
It's not the actual patch (getpwuid), just the static linking as such. Very weird.

[TimoRoth]

It's 100% reproducible for me on two PCs by just opening a new terminal, hitting Ctrl+R, and entering stuff and removing it again a couple times. After 2~4 rounds of that it will close.

I added -h always, and I get "/bin/wslbridge: Exit 1." in red when it happens.

Logfile also contains that same "wslbridge error: connection broken"

Replacing wslbridge.exe and wslbridge-backend with the old version from 3.0.0 makes things work again.

[Tubbles]

I have a similar issue when i try to install rustc in ubuntu 18.04:
sudo apt install rustc

[mintty]

I did not write the code and I have no idea. What part of the code would behave erratically just because of static linking? If we find a clue, maybe there can be a workaround. For now, I will simply drop the static linking patch and release 3.0.1.2 in a minute. The drawback is that Alpine Linux (and possibly others?) will not work again (#156).

[mintty]

Released 3.0.1.2.
Leaving this issue open as we need a workaround that also fixes #156.

[tynanbe]

I've been using my own statically compiled wslbridge-backend and not encountering any of these issues -- it's been rock solid for some weeks.
Tracing back through my steps as best I can remember, with help from command line history.

• wsltty 3.0.1.2
• wslbridge 0.2.5-dev
• Windows Insider: No
• WSL Ubuntu: WSL Legacy Edition, updated to Ubuntu 18.04
• WSL Void Linux, musl variant: https://github.com/am11/VoidMuslWSL
  • For reference -- https://github.com/yuk7/ArchWSL/wiki/How-to-Setup
  • For reference -- https://wiki.voidlinux.org/Post_Installation

---

Steps

1. Modify wslbridge/backend/Makefile as below.
2. Compile with WSL Ubuntu (glibc).

STRIP ?= strip
#		-Wall -O2 $< ../common/SocketIo.cc -o $@ -lutil -pthread

all : ../out/wslbridge-backend

../out/wslbridge-backend : wslbridge-backend.cc ../common/SocketIo.cc ../common/SocketIo.h ../VERSION.txt Makefile
	mkdir -p ../out
	$(CXX) -std=c++11 -fno-exceptions \
		-static-libgcc -static-libstdc++ \
		-D_GNU_SOURCE \
		-DWSLBRIDGE_VERSION=$(shell cat ../VERSION.txt) \
		-Wall -O2 $< ../common/SocketIo.cc -o $@ -lutil -static -pthread \
		-Wl,--whole-archive -lpthread -Wl,--no-whole-archive
	$(STRIP) $@

clean:
	rm -f ../out/wslbridge-backend

See: rprichard/wslbridge#26

---

After dropping in the replacement wslbridge-backend to the installed wsltty/bin, I can run both Ubuntu and Void-musl from wsltty no problem.

I intend to try this again soon after I re-install/upgrade wsltty in my process of moving from using chocolatey back to using scoop.

I didn't investigate whether there are any differences from what you had in the Makefile, but otherwise it'd be great if simply compiling wslbridge-backend from glibc instead of musl fixed #169 and #156.

[mintty]

Is your patch based on the current version, with my previous patch reverted?
So, without the injected implementation of getpwuid?
That gives me
wslbridge-backend.cc:(.text.startup+0x115b): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
If I ignore it, WSL seems to work fine except Alpine (not tried other musl yet) which just closes.
With the getpwuid patch in addition, all WSLs seem to work fine so far.

Thanks for this great discovery. How did you arrive at this solution?

[mintty]

Void and Arch run fine, too. Except, is it correct that they both use the Ubuntu icon?

[tynanbe]

Some hours searching on github issues, mostly. I'm not very experienced with C/C++ compilation apart from a foray into funtoo Linux, including some experimentation with clang.

The solution presented utilizes what I assume is the wsltty 3.0.1.2 release as is, since it was installed via chocolatey. To get VoidMuslWSL working with wsltty from there I cloned the master branch of https://github.com/rprichard/wslbridge and tried to apply the recommended change from rprichard/wslbridge#26 (comment)

Not wanting to muddy my nice, shiny Void-musl install with glibc stuff, I compiled wslbridge-backend with Ubuntu since that distro was comparatively bloated to begin with and had glibc at the ready. Then as mentioned I dropped the new wslbridge-backend file into the already-working wsltty release and it "worked for me".

To your last point it looks like wsltty generated VoidMusl shortcuts with the Ubuntu logo for me too, but I just made my own -- since I prefer to launch fish instead of bash -- and assigned the proper icon from VoidMusl/VoidMusl.exe.

It sounds like you've also got the getpwuid warning fixed -- if so it might prove useful for https://github.com/rprichard/wslbridge too.

[mintty]

About the icon, both "self-made" distros do not have a PackageFamilyName registry entry. Arrgh, yet another way to identify an icon, we love that!
The getpwuid issue is still a problem because the patch relies on /etc/passwd. If a distro doesn't have that, it will fail.

[tynanbe]

When I came across https://github.com/yuk7/wsldl it looked like the Windows 10 "1903" release might obsolete it with the new WSL tools it included. While I was tempted to jump into the early release channels at the time, I didn't want to risk it on my daily driver desktop, so I just went ahead with the wsldl-based VoidMusl instead.

Just something to consider if you think it's worth detecting their icons or seeing if the author would make changes to be more "standardized." It looked like the wsldl author previously thought his project obsolete too, but maybe changed his mind and has still been actively developing it.

[tynanbe]

FYI, distros using musl:
https://wiki.musl-libc.org/projects-using-musl.html
Alpine is probably the most well-known thanks to docker.
Void is probably not as well-known, but is definitely well-supported.
I can't comment on the others listed there and am not aware of any WSL builds for them as yet.

[mintty]

Arrgh, yet another way to identify an icon, we love that!

Uploaded a patch to find proper icon and rootfs.

[mintty]

I've now reintroduced the local getpwuid implementation, amended with getpwuid loaded dynamically, despite static linking, with dlopen.
This works with glibc and musl (tested), and I'd expect it to work with glibc even without /etc/passwd (not tested).
If you can build an installer yourself (from cygwin), I'd welcome any testing. Or I may upload a beta installer.

[tynanbe]

If you can build an installer yourself (from cygwin), I'd welcome any testing. Or I may upload a beta installer.

I'd be happy to test a beta -- I don't have cygwin installed/setup right now.

[mintty]

Pre-release 3.0.2.2 available.

[tynanbe]

With the installed wsltty 3.0.2.2, Ubuntu legacy works fine, and all shortcut icons are properly retrieved, but the following still happens when launching VoidMuslWSL:

/bin/wslbridge: Exit 1.
wslbridge error: failed to start backend process
note: backend error output: /bin/bash: /mnt/u/Users/[...]/AppData/Local/wsltty/bin/wslbridge-backend: No such file or directory

The wslbridge-backend file is also the same size as with 3.0.1.2 -- 789k.
Replacing wslbridge-backend with the one I compiled previously resolves the issue.
The wslbridge-backend that I compiled previously is 1,176k in size.

[tynanbe]

Might be possibly related to the patch file you added.
It seems to reference old and new paths (maybe used during testing) that shouldn't exist in the wslbridge zip that the makefile grabs.

[mintty]

That's only the patch syntax, you can place the diff files whereever you want for generating the patch diff.
Apparently I was under the wrong assumption that all wsldl distros are musl-based, so I had tested only Arch, not Void or Alpine...

[tynanbe]

Sorry to be confusing, Arch isn't musl-based and neither are all wsldl distros. I just had Arch in my reference above because it has the most complete steps on how to set up a wsldl distro after download.

That aside, I would still guess that the patch didn't get applied (properly) because otherwise wslbridge-backend should be a different size from previous releases.

[mintty]

I'm afraid you're right, the build process has a problem and didn't pack the new binary.
Replaced the installer in the pre-release. Now it works with both kinds of distros!

[tynanbe]

Can confirm.
From the replaced wsltty 3.0.2.2 installer I now see a wslbridge-backend sized 1,785k.
Ubuntu legacy WSL and VoidMuslWSL (wsldl) both launch properly and pick up proper icons for the generated shortcuts.
Thanks so much!
Will report back if anything crashes on large amounts of data.

[mintty]

Released 3.0.5 with new WSL gateway.