Repository: microsoft/terminal (language: cpp)

Issue:
Malformed/Partially destroyed Standard output from Visual studio (& others)
### 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;
}
```
4. Set Release and x64 mode.
5. Click on "Start **Without** Debugging" button.
6. Close the terminal.
7. Click on "Start **Without** Debugging" button again.
8. 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](https://user-images.githubusercontent.com/79061723/206486691-0ea1e283-059e-4667-a28e-461c0b49277f.png)

_Note: Classic console works as expected in this scenario._


Discussion / hints:
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
> 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).
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 🙂 
> 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](https://github.com/microsoft/terminal/files/10239678/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](https://user-images.githubusercontent.com/79061723/207938295-6bf51f66-6d5b-4492-a62b-c045a4657811.png)

When I start scrolling:

![after](https://user-images.githubusercontent.com/79061723/207938355-4750b64a-2f20-4581-b558-a4c92019dafd.png)

> 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?

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](https://user-images.githubusercontent.com/63251238/210156203-38e0511f-f9d5-4855-935c-17c50c1d334f.png)

![image](https://user-images.githubusercontent.com/63251238/210156213-adab1bf3-19d7-4698-86a0-0ab236b087d0.png)

As you can see, in this case some output to the right is just missing. It's not wrapped, but missing.

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](https://user-images.githubusercontent.com/63251238/210162930-d0811ec3-9801-4dea-b23c-d1ef295bf970.png)

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 😁
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. 
UNBELEIVABLY[1], I can't repro this on a dev build, but I can on 1.17.3481.0 consistently

I bet this was fixed by the conpty changes in #14544. We don't have that commit in the selfhost build, but we do have it in main. 

I guess I could do my diligence and bisect that commit. 


* 165d3edde9ca850f25f7c1e740b5661461fcf175 (expected: ✅, actual: ✅)
* a3c7bc3349bfc5bbb07b8295871b06331b5e86b5 (expected: ❌, actual: ❌) ~(double checked, this definitely seems ✅ which by all accounts don't make no sense)~ triple checked, no, this doesn't work
* (expected: ❌, actual: ❔)
* b9c3b5cd1e72d0509ab3ce2684004122a62ea79c (expected: ❌, actual: ✅) arbitrarily the bottom of page 1
* (expected: ❌, actual: ❔)
* da2b80bc0a38f5df49a4b987527decb302d16b7b (expected: ❌, actual: ❌)
* (expected: ❌, actual: ❔)
* 4d9a266c12d6bdafa88476279e5761f5eb5ff4fc (expected: ❌, actual: ❌)
* (expected: ❌, actual: ❔)
* 0eff8c06e32bff6c1e8d39e6505ef8a4c6d8ecbf (expected: ❌, actual: ❌)
* (expected: ❌, actual: ❔)
* 62b34cf6f77199df306999f89a5f57368cfa5059 (expected: ❌, actual: ❌) arbitrarily the bottom of page 2

hmm. That's sure weird.

[1]: read as "_somehow totally believably_"

<hr>

1/17 update: Did a whole bisect. It finally landed on a3c7bc3349bfc5bbb07b8295871b06331b5e86b5, which is.... nonsense. Seems like the load of the cpu affects this. More likely to hit while building code. Maybe this _does_ still repro on `main`....
Uhg. I just needed to try more. This must be some strange race, cause I just got this in the current main (4c7879bfb). 

How are we gonna debug this? This is intermittent, timing-based, and occurs via defterm. Defterm means we can't use the debug tap. I'd reckon that attaching to VS would probably break the repro. 

My assumption from before is where I think I'll start:

> 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.

We've got two sets of symptoms here:
* Folks missing lines of output (but the newlines are all seemingly there). This creates blank lines of output in the Terminal
* Places where the entire line (including the newline) are missing. That results in just skipped numbers, but no blank lines:
  ![image](https://user-images.githubusercontent.com/18356694/212971412-9aa0e19c-1bbc-49a2-9d76-958d7c697a7f.png)

I put a test in `dev/migrie/b/14512-test-research`, but that all passed on `main`, so maybe this doesn't exactly have to do with the first frame optimizations. I don't think I'll get eyes on this before the 1.17 cutoff. 
@zadjii-msft I have the same bug. A simple for loop to print 100 lines will show the first 70 empty (only the ones now in view of the final frame of the console mind you, running it at 120x30, if I increase the height it displays it _more_ correctly to a point).

![image](https://user-images.githubusercontent.com/114983496/232397523-26a926f1-26eb-44d8-afc3-244f81072332.png)

Only with the Windows Terminal, not reproducible choosing Windows Console Host as the default. Only happens at the beginning of the program, if I print 10,000 lines the bug affects the first few hundred.

Tried to reset settings.json to no avail. Reproducible in VStudio, CLion, Codeblocks with msvc, gcc and clang. Not reproducible if debugging.
Yeah, still no fix in sight for this?
Scheduled for 1.18 I guess, still no fix. At least it's easy to work around, but it's ugly.

Fix patch:
diff --git a/src/host/VtIo.cpp b/src/host/VtIo.cpp
index f3a4b0228d0..b0f4ebad2c3 100644
--- a/src/host/VtIo.cpp
+++ b/src/host/VtIo.cpp
@@ -25,7 +25,6 @@ using namespace Microsoft::Console::Interactivity;
 
 VtIo::VtIo() :
     _initialized(false),
-    _objectsCreated(false),
     _lookingForCursorPosition(false),
     _IoMode(VtIoMode::INVALID)
 {
@@ -224,13 +223,12 @@ VtIo::VtIo() :
     }
     CATCH_RETURN();
 
-    _objectsCreated = true;
     return S_OK;
 }
 
 bool VtIo::IsUsingVt() const
 {
-    return _objectsCreated;
+    return _initialized;
 }
 
 // Routine Description:
@@ -246,7 +244,7 @@ bool VtIo::IsUsingVt() const
 [[nodiscard]] HRESULT VtIo::StartIfNeeded()
 {
     // If we haven't been set up, do nothing (because there's nothing to start)
-    if (!_objectsCreated)
+    if (!_initialized)
     {
         return S_FALSE;
     }
@@ -514,7 +512,7 @@ void VtIo::EndResize()
 // - <none>
 void VtIo::EnableConptyModeForTests(std::unique_ptr<Microsoft::Console::Render::VtEngine> vtRenderEngine)
 {
-    _objectsCreated = true;
+    _initialized = true;
     _pVtRenderEngine = std::move(vtRenderEngine);
 }
 #endif
diff --git a/src/host/VtIo.hpp b/src/host/VtIo.hpp
index b3661f59d43..e47d37d9ef6 100644
--- a/src/host/VtIo.hpp
+++ b/src/host/VtIo.hpp
@@ -63,7 +63,6 @@ namespace Microsoft::Console::VirtualTerminal
         VtIoMode _IoMode;
 
         bool _initialized;
-        bool _objectsCreated;
 
         bool _lookingForCursorPosition;
 


Test patch: