Neofetch in wsl2(debian) crashes the terminal

[Nithsua]

Environment

Windows build number: 19041.21
Windows Terminal version (if applicable):  0.8.10091.0

Any other software?
Debian in WSL2

Steps to reproduce

1. Open terminal (has wsl2 as default shell)
2. run neofetch

Expected behavior

To show the output of neofetch

Actual behavior

Terminal crashes without any output

[aoahonen]

I'm having this same issue with crashing Windows Terminal when running Neofetch in WSL (Ubuntu 16.04)

Event Viewer log's

Faulting application name: WindowsTerminal.exe, version: 0.8.2001.9001, time stamp: 0x5e17d9ef
Faulting module name: ucrtbase.dll, version: 10.0.18362.387, time stamp: 0x4361b720
Exception code: 0xc0000409
Fault offset: 0x000000000006db8e
Faulting process id: 0x4294
Faulting application start time: 0x01d5cc4225433c98
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.8.10091.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: c83e735f-d600-4a91-8279-8c22e29d0ccc
Faulting package full name: Microsoft.WindowsTerminal_0.8.10091.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

WSL starts as expected (with neofetch) when launching from start menu, or when started with "wsl" or "bash" commands from cmd.exe ("legacy" command prompt)

[nizmow]

Happening to me also, on two separate machines (machine A: WSL2/Ubuntu 19.10, machine B: WSL1/Ubuntu 18.04). On the machine A, I get what looks like the first row of characters in the Ubuntu logo before Terminal freezes for a second and crashes. On machine B, it seems to crash immediately.

More details:

Machine A: Terminal installed from MS Store.
Machine B: Terminal built from source and deployed locally.

EDIT: for the record, I just installed neofetch natively on Windows via scoop and ran it in Powershell -- it works perfectly.

[skyline75489]

I can't seem to reproduce it on my openSUSE distro (Yeah I'm more of a SUSE guy now). It's kind of surprising if this is actually related to distro, though.

EDIT: Ignore the distro thing. This is a regression. Last Store build 0.7.3451.0 is good. Current master 6d6fb7f is bad

[zadjii-msft]

Wow yea that just crashed the Terminal for me too, pretty immediately, with Ubuntu.

Maybe this is related to the #1360/#4150 class of issues, @miniksa could you verify for me?

[armak]

I encountered this issue too with the latest release version, Ubuntu 18.04 WSL (1) (Microsoft Windows [Version 10.0.18362.356]).

[DHowett-MSFT]

@nizmow since you’ve built it from source, you should be able to produce far better debugging information than somebody who installed it from the store. Would you mind?

[ntnlabs]

I have the same issue when I connect from my Win terminal with ssh to another box (pure linux). After entering a correct pass the app crashes. Reading the comments I may add that after I log into another box I get a neofetch info...

[ZhaoMJ]

I just bisected the commits and it seems that #4125 caused this regression.
The error happens at TerminalDispatch::CursorBackward at TerminalDispatch.cpp Line 63. Specifically, narrow_cast() throws since it's unable to cast distance, which has a weird value (9999999) at this point, into short.

[j4james]

This is the result of a CUB escape sequence with a distance of 9999999. I've mentioned this as an issue before - it used to be clamped in the state machine, but that was changed in PR #3956. And the result is it throws an exception in the narrow cast in the TerminalDispatch::CursorBackward handler here:

terminal/src/cascadia/TerminalCore/TerminalDispatch.cpp

Line 63 in 701b421

const COORD newCursorPos{ cursorPos.X - gsl::narrow<short>(distance), cursorPos.Y };

In theory that exception should have been caught, which would still be wrong, but at least not crashing. However, it seems that GSL_TERMINATE_ON_CONTRACT_VIOLATION is set, so the throw_exception call actually just kills the app.

[j4james]

I just bisected the commits and it seems that #4125 caused this regression.

Just to be clear, that's not really the cause. That just fixed an error in the passthrough implementation that was hiding the problem.

[nizmow]

Looks like debugging might not be necessary, but when I get in front of a machine next I’ll give it a shot if still required. Figured it must be an escape sequence.

[miniksa]

This is the result of a CUB escape sequence with a distance of 9999999. I've mentioned this as an issue before - it used to be clamped in the state machine, but that was changed in PR #3956. And the result is it throws an exception in the narrow cast in the TerminalDispatch::CursorBackward handler here:

terminal/src/cascadia/TerminalCore/TerminalDispatch.cpp

Line 63 in 701b421

const COORD newCursorPos{ cursorPos.X - gsl::narrow<short>(distance), cursorPos.Y };

In theory that exception should have been caught, which would still be wrong, but at least not crashing. However, it seems that GSL_TERMINATE_ON_CONTRACT_VIOLATION is set, so the throw_exception call actually just kills the app.

Welp, looks like we need #4144 in so we can get going on #4153 and apply the saturating math here.

[j4james]

As another example of this problem, you can kill conhost in a similar way with the IL and DL sequences (assuming you're using a recent build). For example, in a bash shell do:

printf "\e[9999999L"

I know #4144/#4153 should fix many of these issues eventually, but I think it's a serious enough problem that it's worth reverting the state machine clamping ASAP as a quick fix.

Either way, I think we should be defining GSL_THROW_ON_CONTRACT_VIOLATION instead of using the default GSL_TERMINATE_ON_CONTRACT_VIOLATION. I can't believe we'd actually want the app to just crash if there is an unexpected overflow.

[miniksa]

As another example of this problem, you can kill conhost in a similar way with the IL and DL sequences (assuming you're using a recent build). For example, in a bash shell do:

printf "\e[9999999L"

I know #4144/#4153 should fix many of these issues eventually, but I think it's a serious enough problem that it's worth reverting the state machine clamping ASAP as a quick fix.

Either way, I think we should be defining GSL_THROW_ON_CONTRACT_VIOLATION instead of using the default GSL_TERMINATE_ON_CONTRACT_VIOLATION. I can't believe we'd actually want the app to just crash if there is an unexpected overflow.

I didn't know that was an option. Let's file an issue to consider changing GSL Terminate to GSL Throw.

Also, I just merged #4144 now. We could fix this one particular crash by using the saturating math without waiting for all locations to be fixed as a part of #4153.

[j4james]

Also, I just merged #4144 now. We could fix this one particular crash by using the saturating math without waiting for all locations to be fixed as a part of #4153.

I'm not sure what you had in mind, but if you are just planning to fix it in TerminalDispatch, be aware that that just fixes the crash - the functionality will still be broken. It's only getting as far as TerminalDispatch because it had already failed in conhost. Fixing it in the one but not the other will just leave the two systems out of sync.

[miniksa]

I don't have a specific fix in mind. You just said that it used to be clamped and now it isn't. So I supposed we would use clamping math to fix it. Even if that has to be on both sides of the interface.

[j4james]

I'm not objecting to the use of the new clamping math. I was just suggesting we handle that clamping at the state machine level since that would be the quickest short term solution. If you think it'll be easy to fix everywhere else instead, that'd be great, since that is ultimately what we want - I just thought that would be a lot of work.

[dollproxy]

Same thing happened to me while trying neofetch with the Terminal (preview) from Chocolatey, latest version.

But yeah it seems independent of the distro you run WSL with

[mikelyons]

Does anyone have the procedure for removing neofetch so that I don't have to reconfigure everything?

[DHowett]

@mikelyons you're commenting on a bug with a crash that was fixed 9 months ago. What are you seeing?

[mikelyons]

@DHowett I'm just still seeing WSL terminal crashing immediately on launch after a windows update, latest windows updates don't fix it.

[DHowett]

Please file a new bug. It would also help if you follow the feedback hub steps that (I think) are in the bug template.

[zadjii-msft]

You know, there was discussion of some other related crashes (namely in printf "\e[999999999L") in this thread, but those look like they've been fixed in the meantime as well. Unclear when exactly. But the OP, and the follow-up crashes have been fixed, so I'm gonna close this one out.