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

Malformed/Partially destroyed Standard output from Visual studio (& others) #14512

Closed
ForgotMyCode opened this issue Dec 8, 2022 · 24 comments
Closed
Labels
Area-DefApp In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Conpty For console issues specifically related to conpty Product-Terminal The new Windows Terminal.

Comments

@ForgotMyCode
Copy link

ForgotMyCode commented Dec 8, 2022

Windows Terminal version

1.15.2875.0

Windows build number

10.0.22000.1281

Other Software

Microsoft Visual Studio Community 2022 (64-bit) - Current
Version 17.4.2

Steps to reproduce

  1. In Windows Settings, Windows Terminal should be set as default terminal.
  2. In Visual Studio, create new C++ project, with arbitrary name
  3. In arbitrary named .cpp file, insert this sample code:
#include <iostream>

int main() {	
	for(int i = 0; i < 100; ++i) {
		std::cout << i << '\n';

	}
	return 0;
}
  1. Set Release and x64 mode.
  2. Click on "Start Without Debugging" button.
  3. Close the terminal.
  4. Click on "Start Without Debugging" button again.
  5. Scroll up.

Expected Behavior

I would expect to see previous output lines correctly when I scroll up.

Actual Behavior

There is no output above the previously visible text, or the output is malformed.
bug1

Note: Classic console works as expected in this scenario.

@ForgotMyCode ForgotMyCode added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Dec 8, 2022
@zadjii-msft
Copy link
Member

I could have sworn there was s dupe for this somewhere on the backlog...

Part of me worries that this is defterm specific. Like, the issue wouldn't repro in the Terminal if you launched the sample exe as wt -- sample.exe.

Does selecting the missing output with the mouse cause it to reappear/? If so, this could be #11214

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 12, 2022
@ForgotMyCode
Copy link
Author

ForgotMyCode commented Dec 12, 2022

Does selecting the missing output with the mouse cause it to reappear/?

No, it does not.

I can even select and copy paste everything and the text corresponds to what is visible in the terminal.

In case it has any significance, I did not find a way to reproduce the issue by running the program directly from the terminal (without setting it as default terminal and running it from VS).

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Dec 12, 2022
@DHowett
Copy link
Member

DHowett commented Dec 14, 2022

This is pretty strange, and I can't reproduce it on VS 17.4.0. Can you share your settings.json? I must be missing something 🙂

@DHowett DHowett added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Dec 14, 2022
@ForgotMyCode
Copy link
Author

ForgotMyCode commented Dec 15, 2022

Can you share your settings.json?

I figured it may be easier to reproduce if I just reset the settings to default (I erased everything in the settings.json and restarted the terminal). I am still able to reproduce the issue even with default settings. I any case here is my current settings.json:
settings.zip

There is another little detail I have noticed: the scrollbar behaves pretty weird. Before I start scrolling, it is pretty large, as soon as I start scrolling, it gets way smaller:

Before scrolling:

before

When I start scrolling:

after

I can't reproduce it on VS 17.4.0

That is strange, keep in mind it is (usually) necessary to repeat the process (closing terminal and start without debuggin) several times. I have tried reproducing it in a VM, but I could not, although I have a feeling a reason could be the VM is very slow so the text is printed without being buffered or whatever magic is going on behind the scenes.

Edit: Also if I add a little delay (some heavy computation) before the program starts printing, the issue does not occur. Is it possible the terminal is not "initialized" yet?

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Dec 15, 2022
@LucNanquette
Copy link

LucNanquette commented Dec 31, 2022

I can confirm, that I get exactly the same bug. First I thought it had to do with the 17.5 Preview version of Visual Studio. But even after rolling back from preview, the bug persisted.

I first experienced this bug a few days back. But in that case there was no scrolling involved. Just missing pieces of console output. Like the "Press any key to close this window..." was only displayed as "Press any" and then nothing. But also text in the middle of several outputs was just missing. As I said I fist suspected a bug in Visual Studio, as sometimes the issue could be resolved by switching from debug to release, but then again, this only sometimes worked.

I can reproduce this bug in C# and C++, it doesn't matter.

As has already been stated, a small delay or a Console.Clear() at the beginning solve the issue.

As an example, using Console.WriteLine($"{double.MinValue:N0}\n{double.MaxValue:N0}"); to output the quit large min and max values of doubles: 1st picture without Console.Clear(); 2nd picture with Console.Clear();

image

image

As you can see, in this case some output to the right is just missing. It's not wrapped, but missing.

@LucNanquette
Copy link

LucNanquette commented Jan 1, 2023

Not sure if this helps, but I found that if you leave the terminal window open and then just run the code again, without closing terminal window first, the issue doesn't appear. I can reproduce this all the time; first run = bugs, second run without closing terminal first = no issue.
This also explains, why running the code from the console doesn't get any issues, as the terminal window is already running at that point.
So I guess that @ForgotMyCode is right by assuming it has something to do with the initialization of the terminal. Some sort of buffer problem?
Also I can see, that at the first run, the tab name "Microsoft Visual Studio Debug Console" is followed by some long hex number code? (see screenshot below) This stays for a few seconds before it disappears. On the second run, without closing terminal first, this does not happen.
Also you can see that the test pattern "Testing...{counting}..." is not only cut off at the right, but also misses some chars in between. Scrolling up just reveals empty lines, the first thing displayed being "g...164".

image

@LucNanquette
Copy link

LucNanquette commented Jan 1, 2023

But what really puzzles me is the fact, that I have been experiencing this issue first time a few weeks ago. So it could correspond with the release of v1.15.3466.0 2 weeks ago, but going back to v1.15.2875 doesn't solve the issue.
I don't know what I am missing... tried uninstalling/reinstalling, resetting the .json settings... nothing solved the issue yet, appart from switching from terminal to the Windows Console Host, there everything runs fine.

PS: Happy new year to everyone 😁

@zadjii-msft zadjii-msft added Product-Terminal The new Windows Terminal. Area-DefApp labels Jan 3, 2023
@zadjii-msft
Copy link
Member

You know what, we play all sorts of silly games on "the first paint" for conpty. I bet there's something fucky going on there with outputting more than a whole screen full of text before ConPTY does it's first frame.

I've been out of the codebase for two weeks, but that's where I'd starts.

#14547 has basically the same repro and side effects. I bet they're the same.

@zadjii-msft zadjii-msft added Product-Conpty For console issues specifically related to conpty and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Attention The core contributors need to come back around and look at this ASAP. labels Jan 3, 2023
@zadjii-msft zadjii-msft added this to the Terminal v1.17 milestone Jan 3, 2023
@zadjii-msft

This comment was marked as outdated.

zadjii-msft added a commit that referenced this issue May 5, 2023
This is a theory. I want to audit the uses of `CONSOLE_INFORMATION::IsInVtIoMode` before I commit to this.

But I think this:
* fixes #15245
* fixes #14512

Because basically, we'd create the first screen buffer with 9001 rows, because it would be created _before_ VtIo would be in a state to say "yes, we're a conpty"
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label May 5, 2023
@zadjii-msft
Copy link
Member

I think this is fixed in #15298. I want to check that in to 1.18 and actually verify that this issue is resolved in 1.18, before committing that it closes this thread.

zadjii-msft added a commit that referenced this issue May 10, 2023
We need to act like a ConPTY just a little earlier in startup. My relevant notes start here: #15245 (comment). 

Basically, we'd create the first screen buffer with 9001 rows, because it would be created _before_ VtIo would be in a state to say "yes, we're a conpty". Then, if a CLI app emits an entire screenful of text _before_ the terminal has a chance to resize the conpty, then the conpty will explode during `_DoLineFeed`. That method is absolutely not expecting the buffer to get resized (and the old text buffer deallocated). 

Instead, this will treat the console as in ConPty mode as soon as `VtIo::Initialize` is called (this is during `ConsoleCreateIoThread`, which is right at the end of `ConsoleEstablishHandoff`, which is before the API server starts to process the client connect message).  THEORETICALLY, `VtIo` could `Initialize` then fail to create objects in `CreateIoHandlers` (which is what we used to treat as the moment that we were in conpty mode). However, if we do fail out of `CreateIoHandlers`, then the console itself will fail to start up, and just die. So I don't think that's needed.

This fixes #15245. I think this is PROBABLY also the solution to #14512, but I'm not gonna explicitly mark closed. We'll loop back on it.
@ghost
Copy link

ghost commented May 27, 2023

v1.18.1421.0 fixes the issue for me.

@whshields
Copy link

I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue?

@ghost
Copy link

ghost commented Jun 6, 2023

I'm running Visual Studio Community 17.6.2 and I'm getting the same bug. Anything I can add to my code besides Running without Debugging twice to stitch the issue?

Why not update the Terminal?

You can add a small delay, that's what I did to work around it. Like 50-60 ms or so before you start printing. Or you can switch to the Windows Console.

@zadjii-msft
Copy link
Member

@whshields which Terminal version are you using? This is totally just a bug in the Terminal, regardless of VS version.

I'm really tempted to just close this out now. We seemingly haven't gotten any reports of this in the last month, and it was a pretty noisy bug before that.

@ForgotMyCode
Copy link
Author

ForgotMyCode commented Jul 5, 2023

In case it has any weight, I am still able to reproduce the bug even using the latest (stable) versions (Terminal 1.17.11461.0; VS 17.6.4), but I have noticed it is not consistently reproducible (that said in my case the output is destroyed in almost 100 % of cases), probably depends on a machine's performance if not other factors.

@zadjii-msft
Copy link
Member

That would make sense - the PR I think fixed this (#15298) is only in 1.18 (Preview) builds currently.

@ForgotMyCode
Copy link
Author

ForgotMyCode commented Jul 5, 2023

@zadjii-msft I have tried the preview version, the issue seems to be fixed, well done! So, at least from my side this issue can be closed, if that's ok with you.

@SurfinPixelBird
Copy link

SurfinPixelBird commented Jul 6, 2023

hi i have the same issue since i upgrade to win 11.
you can set the console to legacy mode to use a older console.
RESTART YOUR PC!!!
the output is as expected

legacy

6 hours for a for loop such a workflow

i can confirm that is not a vs bug.
i had the same behaviour with qt.

@ForgotMyCode
Copy link
Author

Fixed in v1.18.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Jul 13, 2023
DHowett pushed a commit that referenced this issue Nov 28, 2023
We need to act like a ConPTY just a little earlier in startup. My relevant notes start here: #15245 (comment).

Basically, we'd create the first screen buffer with 9001 rows, because it would be created _before_ VtIo would be in a state to say "yes, we're a conpty". Then, if a CLI app emits an entire screenful of text _before_ the terminal has a chance to resize the conpty, then the conpty will explode during `_DoLineFeed`. That method is absolutely not expecting the buffer to get resized (and the old text buffer deallocated).

Instead, this will treat the console as in ConPty mode as soon as `VtIo::Initialize` is called (this is during `ConsoleCreateIoThread`, which is right at the end of `ConsoleEstablishHandoff`, which is before the API server starts to process the client connect message).  THEORETICALLY, `VtIo` could `Initialize` then fail to create objects in `CreateIoHandlers` (which is what we used to treat as the moment that we were in conpty mode). However, if we do fail out of `CreateIoHandlers`, then the console itself will fail to start up, and just die. So I don't think that's needed.

This fixes #15245. I think this is PROBABLY also the solution to #14512, but I'm not gonna explicitly mark closed. We'll loop back on it.

(cherry picked from commit 6ad8cd0)
Service-Card-Id: 89112504
Service-Version: 1.17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-DefApp In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Conpty For console issues specifically related to conpty Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

6 participants