starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-05-06 20:34:29 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Neofetch in wsl2(debian) crashes the terminal #5974

New Issue
Closed
opened 2026-01-31 00:26:50 +00:00 by claunia · 35 comments
claunia commented 2026-01-31 00:26:50 +00:00
Owner
Copy Link

Originally created by @nithsua on GitHub (Jan 16, 2020).

Originally assigned to: @miniksa, @zadjii-msft on GitHub.

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

Originally created by @nithsua on GitHub (Jan 16, 2020). Originally assigned to: @miniksa, @zadjii-msft on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none 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 <!-- A description of how to trigger this bug. --> # Expected behavior To show the output of neofetch <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior Terminal crashes without any output <!-- What's actually happening? -->
claunia commented 2026-01-31 00:26:51 +00:00
Author
Owner
Copy Link

@aoahonen commented on GitHub (Jan 16, 2020):

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)

@aoahonen commented on GitHub (Jan 16, 2020): 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)
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@nizmow commented on GitHub (Jan 16, 2020):

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.

@nizmow commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jan 16, 2020):

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

@skyline75489 commented on GitHub (Jan 16, 2020): 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
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 16, 2020):

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?

@zadjii-msft commented on GitHub (Jan 16, 2020): 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?
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@armak commented on GitHub (Jan 16, 2020):

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

@armak commented on GitHub (Jan 16, 2020): I encountered this issue too with the latest release version, Ubuntu 18.04 WSL (1) (Microsoft Windows [Version 10.0.18362.356]).
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 16, 2020):

@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?

@DHowett-MSFT commented on GitHub (Jan 16, 2020): @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?
claunia commented 2026-01-31 00:26:52 +00:00
Author
Owner
Copy Link

@ntnlabs commented on GitHub (Jan 16, 2020):

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

@ntnlabs commented on GitHub (Jan 16, 2020): 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...
claunia commented 2026-01-31 00:26:53 +00:00
Author
Owner
Copy Link

@ZhaoMJ commented on GitHub (Jan 16, 2020):

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.

@ZhaoMJ commented on GitHub (Jan 16, 2020): 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`.
claunia commented 2026-01-31 00:26:53 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 16, 2020):

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:

701b421286/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 commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:53 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 16, 2020):

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.

@j4james commented on GitHub (Jan 16, 2020): > 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.
claunia commented 2026-01-31 00:26:54 +00:00
Author
Owner
Copy Link

@nizmow commented on GitHub (Jan 16, 2020):

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.

@nizmow commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:54 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 16, 2020):

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:

701b421286/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.

@miniksa commented on GitHub (Jan 16, 2020): > 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.
claunia commented 2026-01-31 00:26:54 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 16, 2020):

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.

@j4james commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:54 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 16, 2020):

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.

@miniksa commented on GitHub (Jan 16, 2020): > 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.
claunia commented 2026-01-31 00:26:55 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 16, 2020):

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.

@j4james commented on GitHub (Jan 16, 2020): > 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.
claunia commented 2026-01-31 00:26:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 16, 2020):

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.

@miniksa commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:55 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 16, 2020):

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.

@j4james commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:55 +00:00
Author
Owner
Copy Link

@dollproxy commented on GitHub (Jan 16, 2020):

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

@dollproxy commented on GitHub (Jan 16, 2020): 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
claunia commented 2026-01-31 00:26:56 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 16, 2020):

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.

@miniksa commented on GitHub (Jan 16, 2020): 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.
claunia commented 2026-01-31 00:26:56 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jan 17, 2020):

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

@skyline75489 commented on GitHub (Jan 17, 2020): With the newly merged PRs, on 2fec1787a038e8fe11fb4ce249451c13891532e1 this seems to be fixed.
claunia commented 2026-01-31 00:26:56 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 17, 2020):

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.

@j4james commented on GitHub (Jan 17, 2020): 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.
claunia commented 2026-01-31 00:26:56 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 17, 2020):

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 commented on GitHub (Jan 17, 2020): 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.
claunia commented 2026-01-31 00:26:56 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 17, 2020):

OK, I pushed a thing here 64f4de5067.

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.

@miniksa commented on GitHub (Jan 17, 2020): 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.
claunia commented 2026-01-31 00:26:57 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 18, 2020):

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

64f4de5067/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.

@j4james commented on GitHub (Jan 18, 2020): 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.
claunia commented 2026-01-31 00:26:57 +00:00
Author
Owner
Copy Link

@minchinweb commented on GitHub (Jan 18, 2020):

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!

@minchinweb commented on GitHub (Jan 18, 2020): 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!
claunia commented 2026-01-31 00:26:57 +00:00
Author
Owner
Copy Link

@ckrailo commented on GitHub (Jan 19, 2020):

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.

@ckrailo commented on GitHub (Jan 19, 2020): 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.
claunia commented 2026-01-31 00:26:57 +00:00
Author
Owner
Copy Link

@rashil2000 commented on GitHub (Jan 19, 2020):

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.

@rashil2000 commented on GitHub (Jan 19, 2020): > 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.
claunia commented 2026-01-31 00:26:57 +00:00
Author
Owner
Copy Link

@mkitzan commented on GitHub (Jan 21, 2020):

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 77dd51af39 when neofetch is run it works:
neofetch

@mkitzan commented on GitHub (Jan 21, 2020): 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: <img width="754" alt="neofetch" src="https://user-images.githubusercontent.com/28279285/72764710-229ff000-3b9e-11ea-9ca2-daa9f46e37ce.PNG">
claunia commented 2026-01-31 00:26:58 +00:00
Author
Owner
Copy Link

@sgtnasty commented on GitHub (Jan 24, 2020):

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

@sgtnasty commented on GitHub (Jan 24, 2020): I have this same issue. It happens on WSL and when I remote into another Linux system.
claunia commented 2026-01-31 00:26:58 +00:00
Author
Owner
Copy Link

@finia2NA commented on GitHub (Jan 26, 2020):

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

@finia2NA commented on GitHub (Jan 26, 2020): 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
claunia commented 2026-01-31 00:26:58 +00:00
Author
Owner
Copy Link

@mikelyons commented on GitHub (Oct 16, 2020):

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

@mikelyons commented on GitHub (Oct 16, 2020): Does anyone have the procedure for removing neofetch so that I don't have to reconfigure everything?
claunia commented 2026-01-31 00:26:58 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 16, 2020):

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

@DHowett commented on GitHub (Oct 16, 2020): @mikelyons you're commenting on a bug with a crash that was fixed 9 months ago. _What are you seeing?_
claunia commented 2026-01-31 00:26:59 +00:00
Author
Owner
Copy Link

@mikelyons commented on GitHub (Dec 4, 2020):

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

@mikelyons commented on GitHub (Dec 4, 2020): @DHowett I'm just still seeing WSL terminal crashing immediately on launch after a windows update, latest windows updates don't fix it.
claunia commented 2026-01-31 00:26:59 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 4, 2020):

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

@DHowett commented on GitHub (Dec 4, 2020): _Please file a new bug_. It would also help if you follow the feedback hub steps that (I think) are in the bug template.
claunia commented 2026-01-31 00:26:59 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 13, 2021):

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.

@zadjii-msft commented on GitHub (Jul 13, 2021): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Issue-Bug Priority-2 Product-Conhost Resolution-Fix-Available
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5974
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?