Terminal: Neofetch in wsl2(debian) crashes the terminal

[austinmarner]

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 6d6fb7f690 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:

https://github.com/microsoft/terminal/blob/701b4212863e9bc4dca2998da03e1b3fbedf7df2/src/cascadia/TerminalCore/TerminalDispatch.cpp#L63

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:

https://github.com/microsoft/terminal/blob/701b4212863e9bc4dca2998da03e1b3fbedf7df2/src/cascadia/TerminalCore/TerminalDispatch.cpp#L63

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.

[PratesM]

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

[miniksa]

Sorry @j4james, I'm just trying to imply that I didn't put a full measure of thought into my fix-strategy for this yet and am just heuristically answering based on the text content of this discussion.

I've assigned it to myself to investigate in full either later today or tomorrow and come up with a suitable proposal, whether that's a fix on the surface or a fix in depth which likely, in some form, will use saturating math. I just need some time to think about it and I haven't had any yet. I'm trying to burn out the giant list of PRs that people want my attention on.

[skyline75489]

With the newly merged PRs, on 2fec1787a038e8fe11fb4ce249451c13891532e1 this seems to be fixed.

[j4james]

Yeah, the new cursor movement code from #3628 should help, because it doesn't fail the same way previous implementation did. You shouldn't get out-of-range cursor movements passing through to the Windows Terminal, so less chance of a crash there. However, it was still written with the assumption of clamped inputs, so it's possible to overflow. You're just more likely to get a weird result rather than a crash.

[miniksa]

OK I am also no longer seeing the neofetch crash so that slightly reduces the priority of this issue.

I do see the \e[999999999L one so I'll work on fixing that one with urgency as the crash.

I'll also go back before 2fec178 and try to further evaluate the quick vs. short fix thing that @j4james alluded to yesterday that I didn't get the chance to fully comprehend before this apparently got partially mitigated by #3628.

[miniksa]

OK, I pushed a thing here https://github.com/microsoft/terminal/commit/64f4de5067d7a93793df1d5f4825d10e79a5ef2f.

I still don't totally like it.

I think I still need to:

• [ ] Fix TextBuffer::_ScrollScreen such that attempting to move large regions doesn't cause an out-of-bounds issue in std::rotate.
• [ ] Fix TextBuffer::_ScrollScreen such that attempting to rotate the entire buffer around multiple times is either condensed into the minimal form (that is rotating +11 on a 5 size buffer only moves +1) or is rejected with an error
• [ ] Inspect ScrollRegion to see why it is accepting destinationOriginGiven that can be wildly outside the bounds of the buffer by checking what conhostv1 used to do in this circumstance
• [ ] Author a test that validates a destinationOriginGiven that is significantly out of bounds (UT on the method & FT on the related conhost API, hopefully)
• [ ] Check the other DoSrvPrivate APIs for gsl::narrow behaviors that can throw for too-big-of-SHORTs and make them clamp things down appropriately.

Some to most of these may become follow up work items.

[j4james]

Note that one of the ways in which you can get destinationOriginGiven wildly out of bounds is when the destination calculation overflows here:

https://github.com/microsoft/terminal/blob/64f4de5067d7a93793df1d5f4825d10e79a5ef2f/src/host/getset.cpp#L2060

Even with the count now being clamped, the Y coordinate can still easily overflow into a very large negative number. Most of the time you probably won't notice, because it's still just going to clear out the source region and ignore the target. But there are some edge cases where I think it does the wrong thing.

Not that this is a new issue, mind you. It's just one of the areas I was expecting us to clean up as part of #4153.

[MinchinWeb]

I'll just add that I ran into this today too. Window 10 Home version 10.0.18363 ("normal" ring), WSL version 1, Ubuntu 18.04.3 (installed through the Windows Store), Terminal version 0.8.10091.0 (also from the Windows store), and neofetch version 3.4.0 (installed via apt).

Neofetch will run in the "regular" Ubuntu window (if I select Ubuntu from the Start Menu) without issue, but if run under a Terminal tab, it hangs hard: Terminal goes completely unresponsive (I can't even switch tabs), and I can't kill it with Task Manager. The only way I've found to can get it working again is to restart Windows!

[ckrailo]

As a user (store-installed), I just want to thank everybody for the work here. Much appreciated!

I wasn't sure what was happening the other day when Terminal started crashing but running the Ubuntu app (also store-installed) still worked. Ubuntu was my default-opening tab, neofetch was running as part of .bashrc, womp womp...

I blasted my old profiles JSON, discovered the blog post saying it needed to be updated to the current format anyway, and when that didn't work I started commenting out .bashrc lines until I found the offending one (neofetch). Leading me to here, where I'm delighted to find this thread I can subscribe to.

Thanks again.

[rashil2000]

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

Can confirm this, I installed Kali from the Store a couple days ago, everything seemed to run fine.
Both the apt-installed and source-built versions of neofetch crashed Terminal abruptly. I thought it was problem related to Kali. Today I was ssh'd (from PowerShell) into a Linux machine, and tried to run source-built neofetch from there. Crashed there too.
It runs fine on legacy PowerShell though.

[mkitzan]

Noticed some weird behavior when trying to get a repro. The WT preview build crashes when neofetch is run, but in the dev build as of 77dd51af39d4f083403bbbe34052f6bdcada9ec3 when neofetch is run it works:

[sgtnasty]

I have this same issue. It happens on WSL and when I remote into another Linux system.

[finia2NA]

Happens to me too with Ubuntu WSL2 when I ssh into my pi which has neofetch in its profile script
I'm on version 0.8.10091.0

[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?_