Neofetch in wsl2(debian) crashes the terminal

Environment

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

Any other software?
Debian in WSL2

Steps to reproduce

Open terminal (has wsl2 as default shell)
run neofetch

Expected behavior

To show the output of neofetch

Actual behavior

Terminal crashes without any output

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)

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.

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

Michael Niksa (@miniksa)

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, Michael Niksa (@miniksa) could you verify for me?

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

Neil Houghton (@nizmow)

Neil Houghton (@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?

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

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.

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.

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.

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.

Mike Lyons (@mikelyons)

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

Dustin L. Howett (@DHowett)

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

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

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.

Navigation Menu

Repository navigation

Neofetch in wsl2(debian) crashes the terminal #4254

Environment

Steps to reproduce

Expected behavior

Actual behavior

41 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Neofetch in wsl2(debian) crashes the terminal #4254

Description

Environment

Steps to reproduce

Expected behavior

Actual behavior

Activity

aoahonen commented on Jan 16, 2020

nizmow commented on Jan 16, 2020

skyline75489 commented on Jan 16, 2020

zadjii-msft commented on Jan 16, 2020

armak commented on Jan 16, 2020

DHowett-MSFT commented on Jan 16, 2020

ntnlabs commented on Jan 16, 2020

ZhaoMJ commented on Jan 16, 2020

j4james commented on Jan 16, 2020

j4james commented on Jan 16, 2020

nizmow commented on Jan 16, 2020

41 remaining items

DHowett commented on Oct 15, 2020

mikelyons commented on Dec 4, 2020

DHowett commented on Dec 4, 2020

zadjii-msft commented on Jul 13, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions