Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resetting WSLv1 shell does not start from terminal top #6917

Closed
vadimkantorov opened this issue Jul 14, 2020 · 8 comments
Closed

Resetting WSLv1 shell does not start from terminal top #6917

vadimkantorov opened this issue Jul 14, 2020 · 8 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@vadimkantorov
Copy link

Version: 1.0.1811.0

After typing reset in my WSLv1 shell, I get this. Unfortunately, I do not have a stable repro. Stumbled on this in a long-running Terminal session.
image

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 14, 2020
@zadjii-msft
Copy link
Member

I'd bet that @j4james magically knows exactly what this is. If he doesn't, then I'm not really sure what we can do to investigate this without some sort of stable repro...

@DHowett
Copy link
Member

DHowett commented Jul 14, 2020

Thanks for the report! This was fixed in PR #6763, and is a /dup of #6545

@ghost
Copy link

ghost commented Jul 14, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jul 14, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 14, 2020
@vadimkantorov
Copy link
Author

In general it may be cool to somehow enable « tracing » mode that would collect information about current state of terminal and could record characters/events. Then this trace/log could be uploaded here for cases when a repro is hard to find.

Maybe there can be a limited, but still useful scope of this idea

@DHowett
Copy link
Member

DHowett commented Jul 14, 2020

So, we do actually have something like that! It's the "debug tap", and it shows what's coming out of the PTY infrastructure.

If you set the global setting debugFeatures to true and then hold own left+right Alt while opening a new tab, you'll get this:

image

(the red on the right is the input stream -- right now, i'm running in win32 input mode where each key is transformed into an entire sequence capturing scancode/vkey/repeat/modifiers (#4999), so it's a little verbose.)

@DHowett
Copy link
Member

DHowett commented Jul 14, 2020

There's also local tracing accessible through a wprp file in our source folder. 😄

@vadimkantorov
Copy link
Author

Wow. I think it would be super-cool to make it more accessible to users (with an instruction how to record and view/upload such a trace?) :) Probably many more "stable repro"-less bugs would be less frustrating to report.

What is "source folder"? (I didn't build terminal from source)

@DHowett
Copy link
Member

DHowett commented Jul 15, 2020

Ah, I definitely meant "the folder with the source code in it". The tracing tools that ship with windows are not particularly user-friendly, and as such neither is our wprp file. 😦

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

3 participants