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

[ConPTY] Resizing ConPTY is sometimes ignored if executed near (before/after) a call to attach a client #14201

New Issue
Closed
opened 2026-01-31 04:03:37 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 04:03:37 +00:00
Owner
Copy Link

Originally created by @o-sdn-o on GitHub (Jun 10, 2021).

Windows Terminal version (or Windows build number)

build from source (conhost.exe replaced by OpenConsole.exe)

Other Software

Terminal multiplexer: vtm 0.4.0 (https://github.com/netxs-group/VTM)

Steps to reproduce

Resize ConPTY several times immediately after creation.

In vtm, ConPTY is used as an element within a structure of interconnected elements. This is something like WPF.

The resulting size of the control depends on dynamically added sub-elements, so the final size of the ConPTY is not known at the time of its creation. The size is calculated step by step during the construction of the final object. This is usually two or three very quick iterations after the ConPTY is created.

Here is an example:

Creating a window with powershell. The intermediate size of the ConPTY during creation is 104x11 (~half the window), but by the time the object is created, the ConPTY should be 104x21.

https://user-images.githubusercontent.com/11535558/121590076-501a6180-ca51-11eb-9fea-cb541a51a626.mp4

The following sequence is executed

  • CreatePseudoConsole(104x11 ...
  • CreateProcess( ..powershell...
  • ...
  • ResizePseudoConsole(hPC, 104x11);
  • ...
  • ResizePseudoConsole(hPC, 104x21);

Expected Behavior

ConPTY must be the last requested size.

Actual Behavior

ConPTY is not the last requested size.

Originally created by @o-sdn-o on GitHub (Jun 10, 2021). ### Windows Terminal version (or Windows build number) build from source (conhost.exe replaced by OpenConsole.exe) ### Other Software Terminal multiplexer: vtm 0.4.0 (https://github.com/netxs-group/VTM) ### Steps to reproduce Resize ConPTY ~~several times~~ immediately after creation. In vtm, ConPTY is used as an element within a structure of interconnected elements. This is something like WPF. The resulting size of the control depends on dynamically added sub-elements, so the final size of the ConPTY is not known at the time of its creation. The size is calculated step by step during the construction of the final object. This is usually two or three very quick iterations after the ConPTY is created. Here is an example: Creating a window with `powershell`. The intermediate size of the ConPTY during creation is `104x11` (~half the window), but by the time the object is created, the ConPTY should be `104x21`. https://user-images.githubusercontent.com/11535558/121590076-501a6180-ca51-11eb-9fea-cb541a51a626.mp4 The following sequence is executed - `CreatePseudoConsole(104x11 ...` - `CreateProcess( ..powershell...` - ... - `ResizePseudoConsole(hPC, 104x11);` - ... - `ResizePseudoConsole(hPC, 104x21);` ### Expected Behavior ConPTY must be the last requested size. ### Actual Behavior ConPTY is not the last requested size.
claunia commented 2026-01-31 04:03:38 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 11, 2021):

Resizing once immediately after creation is also sometimes ignored.

@o-sdn-o commented on GitHub (Jun 11, 2021): Resizing once immediately after creation is also sometimes ignored.
claunia commented 2026-01-31 04:03:38 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 11, 2021):

The behavior can be temporarily fixed (for me) by adding

std::this_thread::sleep_for(250ms);

right after

CreatePseudoConsole(...);
CreateProcess(...cli_app...);

This increases the success of the resizing.

@o-sdn-o commented on GitHub (Jun 11, 2021): The behavior can be temporarily fixed (for me) by adding ```c++ std::this_thread::sleep_for(250ms); ``` right after ```c++ CreatePseudoConsole(...); CreateProcess(...cli_app...); ``` This increases the success of the resizing.
claunia commented 2026-01-31 04:03:38 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 12, 2021):

I tried to reproduce this issue with the following code, but it doesn't seem to reproduce that way

test_10400.cpp:

#include <windows.h>
#include <iostream>
#include <vector>
#include <string>
#include <thread>
#include <chrono>

int main(int argc, char* argv[])
{
    using namespace std::chrono_literals;
    COORD consz{ 80, 20 };
    if (argc > 1)
    {
        std::this_thread::sleep_for(250ms);
        auto board = GetStdHandle(STD_OUTPUT_HANDLE);
        CONSOLE_SCREEN_BUFFER_INFO cinfo;
        GetConsoleScreenBufferInfo(board, &cinfo);
        std::cout << "initial size: " << consz.X << " x " << consz.Y << std::endl;
        std::cout << "after resize: " << cinfo.srWindow.Right - cinfo.srWindow.Left + 1
                             << " x " << cinfo.srWindow.Bottom - cinfo.srWindow.Top + 1;
        std::cout << "!";
    }
    else
    {
        char cmdline[] = "test_10400.exe test";
        HPCON hPC{ INVALID_HANDLE_VALUE };
        HANDLE s_pipe_r{ INVALID_HANDLE_VALUE };
        HANDLE s_pipe_w{ INVALID_HANDLE_VALUE };
        HANDLE m_pipe_r{ INVALID_HANDLE_VALUE };
        HANDLE m_pipe_w{ INVALID_HANDLE_VALUE };
        STARTUPINFOEX       start_info{ sizeof(STARTUPINFOEX) };
        PROCESS_INFORMATION procs_info{};
        std::vector<char>   attrs_buff;
        SIZE_T              attrs_size = 0;

        CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0);
        CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0);
        CreatePseudoConsole(consz, s_pipe_r, s_pipe_w, 0, &hPC);

        InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size);
        attrs_buff.resize(attrs_size);
        start_info.lpAttributeList = reinterpret_cast<LPPROC_THREAD_ATTRIBUTE_LIST>(attrs_buff.data());
        InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size);
        UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr);

        //consz = { 80, 40 };
        //ResizePseudoConsole(hPC, consz);

        CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info);

        consz = { 80, 40 };
        ResizePseudoConsole(hPC, consz);

        char c = 0;
        while (true)
        {
            ReadFile(m_pipe_r, &c, 1, nullptr, nullptr);
            if (c == '!') break;
            else std::cout << c;
        }
    }
}

console output:

initial size: 80 x 20
after resize: 80 x 40
@o-sdn-o commented on GitHub (Jun 12, 2021): I tried to reproduce this issue with the following code, but it doesn't seem to reproduce that way `test_10400.cpp`: ```c++ #include <windows.h> #include <iostream> #include <vector> #include <string> #include <thread> #include <chrono> int main(int argc, char* argv[]) { using namespace std::chrono_literals; COORD consz{ 80, 20 }; if (argc > 1) { std::this_thread::sleep_for(250ms); auto board = GetStdHandle(STD_OUTPUT_HANDLE); CONSOLE_SCREEN_BUFFER_INFO cinfo; GetConsoleScreenBufferInfo(board, &cinfo); std::cout << "initial size: " << consz.X << " x " << consz.Y << std::endl; std::cout << "after resize: " << cinfo.srWindow.Right - cinfo.srWindow.Left + 1 << " x " << cinfo.srWindow.Bottom - cinfo.srWindow.Top + 1; std::cout << "!"; } else { char cmdline[] = "test_10400.exe test"; HPCON hPC{ INVALID_HANDLE_VALUE }; HANDLE s_pipe_r{ INVALID_HANDLE_VALUE }; HANDLE s_pipe_w{ INVALID_HANDLE_VALUE }; HANDLE m_pipe_r{ INVALID_HANDLE_VALUE }; HANDLE m_pipe_w{ INVALID_HANDLE_VALUE }; STARTUPINFOEX start_info{ sizeof(STARTUPINFOEX) }; PROCESS_INFORMATION procs_info{}; std::vector<char> attrs_buff; SIZE_T attrs_size = 0; CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0); CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0); CreatePseudoConsole(consz, s_pipe_r, s_pipe_w, 0, &hPC); InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size); attrs_buff.resize(attrs_size); start_info.lpAttributeList = reinterpret_cast<LPPROC_THREAD_ATTRIBUTE_LIST>(attrs_buff.data()); InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size); UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr); //consz = { 80, 40 }; //ResizePseudoConsole(hPC, consz); CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info); consz = { 80, 40 }; ResizePseudoConsole(hPC, consz); char c = 0; while (true) { ReadFile(m_pipe_r, &c, 1, nullptr, nullptr); if (c == '!') break; else std::cout << c; } } } ``` console output: ``` initial size: 80 x 20 after resize: 80 x 40 ```
claunia commented 2026-01-31 04:03:39 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 12, 2021):

Sorry for machine translation, English is not my native language.

I was able to quickly reproduce this issue. Fires one in ten times if you use the following startup line

char cmdline[] = "powershell -command \"'initial size: 80 x 10'; while ($true) { $host.UI.RawUI.WindowSize; start-sleep 1; }\"";

as a command in CreateProcessA().

The following code reproduces the issue from about ten times on my system:

#include <windows.h>
#include <iostream>
#include <vector>

int main()
{
    COORD consz{ 80, 10 };
    char cmdline[] = "powershell -command \"'initial size: 80 x 10'; while ($true) { $host.UI.RawUI.WindowSize; start-sleep 1; }\"";
    HPCON hPC{ INVALID_HANDLE_VALUE };
    HANDLE s_pipe_r{ INVALID_HANDLE_VALUE };
    HANDLE s_pipe_w{ INVALID_HANDLE_VALUE };
    HANDLE m_pipe_r{ INVALID_HANDLE_VALUE };
    HANDLE m_pipe_w{ INVALID_HANDLE_VALUE };
    STARTUPINFOEX       start_info{ sizeof(STARTUPINFOEX) };
    PROCESS_INFORMATION procs_info{};
    std::vector<char>   attrs_buff;
    SIZE_T              attrs_size = 0;

    CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0);
    CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0);
    CreatePseudoConsole(consz, s_pipe_r, s_pipe_w, 0, &hPC);
        
    InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size);
    attrs_buff.resize(attrs_size);
    start_info.lpAttributeList = reinterpret_cast<LPPROC_THREAD_ATTRIBUTE_LIST>(attrs_buff.data());
    InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size);
    UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr);

    CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info);

    consz = { 160, 70 };
    auto hr = ResizePseudoConsole(hPC, consz);
    if (hr != S_OK) // always ok!
    {
        std::cout << "ResizePseudoConsole returns " << hr;
        return 1;
    }

    char c = 0;
    while (true)
    {
        ReadFile(m_pipe_r, &c, 1, nullptr, nullptr);
        std::cout << c;
    }
}

output:

initial size: 80 x 10

Width Height
----- ------
  160     70
  160     70
  160     70
  160     70
^C
D:\sources\temp\test_10400\x64\Release>test_10400.exe

initial size: 80 x 10

Width Height
----- ------
   80     10
   80     10
   80     10
   80     10
^C
D:\sources\temp\test_10400\x64\Release>
@o-sdn-o commented on GitHub (Jun 12, 2021): __Sorry for machine translation, English is not my native language.__ I was able to quickly reproduce this issue. Fires one in ten times if you use the following startup line ```c++ char cmdline[] = "powershell -command \"'initial size: 80 x 10'; while ($true) { $host.UI.RawUI.WindowSize; start-sleep 1; }\""; ``` as a command in `CreateProcessA()`. The following code reproduces the issue from about ten times on my system: ```c++ #include <windows.h> #include <iostream> #include <vector> int main() { COORD consz{ 80, 10 }; char cmdline[] = "powershell -command \"'initial size: 80 x 10'; while ($true) { $host.UI.RawUI.WindowSize; start-sleep 1; }\""; HPCON hPC{ INVALID_HANDLE_VALUE }; HANDLE s_pipe_r{ INVALID_HANDLE_VALUE }; HANDLE s_pipe_w{ INVALID_HANDLE_VALUE }; HANDLE m_pipe_r{ INVALID_HANDLE_VALUE }; HANDLE m_pipe_w{ INVALID_HANDLE_VALUE }; STARTUPINFOEX start_info{ sizeof(STARTUPINFOEX) }; PROCESS_INFORMATION procs_info{}; std::vector<char> attrs_buff; SIZE_T attrs_size = 0; CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0); CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0); CreatePseudoConsole(consz, s_pipe_r, s_pipe_w, 0, &hPC); InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size); attrs_buff.resize(attrs_size); start_info.lpAttributeList = reinterpret_cast<LPPROC_THREAD_ATTRIBUTE_LIST>(attrs_buff.data()); InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size); UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr); CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info); consz = { 160, 70 }; auto hr = ResizePseudoConsole(hPC, consz); if (hr != S_OK) // always ok! { std::cout << "ResizePseudoConsole returns " << hr; return 1; } char c = 0; while (true) { ReadFile(m_pipe_r, &c, 1, nullptr, nullptr); std::cout << c; } } ``` output: ``` initial size: 80 x 10 Width Height ----- ------ 160 70 160 70 160 70 160 70 ^C D:\sources\temp\test_10400\x64\Release>test_10400.exe initial size: 80 x 10 Width Height ----- ------ 80 10 80 10 80 10 80 10 ^C D:\sources\temp\test_10400\x64\Release> ```
claunia commented 2026-01-31 04:03:39 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 12, 2021):

With the following sequence of calls, the issue also occurs, but more often:

    ...
    CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0);
    CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0);
    CreatePseudoConsole({ 80, 10 }, s_pipe_r, s_pipe_w, 0, &hPC);
    ResizePseudoConsole(hPC, { 160, 70 });  // always =S_OK

    InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size);
    attrs_buff.resize(attrs_size);
    start_info.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)attrs_buff.data();
    InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size);
    UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr);
    CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info);
    ...
@o-sdn-o commented on GitHub (Jun 12, 2021): With the following sequence of calls, the issue also occurs, but more often: ```c++ ... CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0); CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0); CreatePseudoConsole({ 80, 10 }, s_pipe_r, s_pipe_w, 0, &hPC); ResizePseudoConsole(hPC, { 160, 70 }); // always =S_OK InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size); attrs_buff.resize(attrs_size); start_info.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)attrs_buff.data(); InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size); UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr); CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info); ... ```
claunia commented 2026-01-31 04:03:39 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 12, 2021):

With the following sequence of calls, I cannot reproduce the issue:

    ...
    CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0);
    CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0);
    CreatePseudoConsole({ 80, 10 }, s_pipe_r, s_pipe_w, 0, &hPC);
    ResizePseudoConsole(hPC, { 160, 70 });

    std::this_thread::sleep_for(1000ms);

    InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size);
    attrs_buff.resize(attrs_size);
    start_info.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)attrs_buff.data();
    InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size);
    UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr);

    CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info);
    ...

but without std::this_thread::sleep_for(1000ms); issue is reproduced.

@o-sdn-o commented on GitHub (Jun 12, 2021): With the following sequence of calls, I cannot reproduce the issue: ```c++ ... CreatePipe(&m_pipe_r, &s_pipe_w, nullptr, 0); CreatePipe(&s_pipe_r, &m_pipe_w, nullptr, 0); CreatePseudoConsole({ 80, 10 }, s_pipe_r, s_pipe_w, 0, &hPC); ResizePseudoConsole(hPC, { 160, 70 }); std::this_thread::sleep_for(1000ms); InitializeProcThreadAttributeList(nullptr, 1, 0, &attrs_size); attrs_buff.resize(attrs_size); start_info.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)attrs_buff.data(); InitializeProcThreadAttributeList(start_info.lpAttributeList, 1, 0, &attrs_size); UpdateProcThreadAttribute(start_info.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), nullptr, nullptr); CreateProcessA(nullptr, cmdline, nullptr, nullptr, FALSE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, (LPSTARTUPINFOA)&start_info.StartupInfo, &procs_info); ... ``` but without `std::this_thread::sleep_for(1000ms);` issue is reproduced.
claunia commented 2026-01-31 04:03:39 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 13, 2021):

If we put the start of the signal thread RETURN_IF_FAILED(_pPtySignalInputThread->Start()); right after we inform that the console is connected _pPtySignalInputThread->ConnectConsole();, then the issue cannot be reproduced.

line 291:
92f0700d5d/src/host/VtIo.cpp (L286-L297)

place after 257:
92f0700d5d/src/host/VtIo.cpp (L254-L261)

I do not know if it is possible to do this, these are just experiments. With this fix, as a first approximation, everything works.

@o-sdn-o commented on GitHub (Jun 13, 2021): If we put the start of the signal thread `RETURN_IF_FAILED(_pPtySignalInputThread->Start());` right after we inform that the console is connected `_pPtySignalInputThread->ConnectConsole();`, then the issue cannot be reproduced. line 291: https://github.com/microsoft/terminal/blob/92f0700d5d7e89141eba225442810519a4d10235/src/host/VtIo.cpp#L286-L297 place after 257: https://github.com/microsoft/terminal/blob/92f0700d5d7e89141eba225442810519a4d10235/src/host/VtIo.cpp#L254-L261 I do not know if it is possible to do this, these are just experiments. With this fix, as a first approximation, everything works.
claunia commented 2026-01-31 04:03:40 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jun 17, 2021):

I think I see what is going on here. It looks like this code is attempting to quick change the startup size of the initial console allocation before another thread gets to allocating the buffer. But depending on the speed of things.... the buffer might have already been initialized.

b3b648496e/src/host/PtySignalInputThread.cpp (L96-L107)

When I trace the code history back into 2018, before we went open source, this code was initially written to just call s_ResizeWindow always without the special early-case. But it looks like that had a few problems:

  1. If the s_ResizeWindow goes off before most of the console buffers are set up, it runs into unexpected uninitialized situations.
  2. If the signal thread blocks itself until everything else is ready... it's not able to detect when the handle/pipe is broken which is a shutdown indicator for ConPTY.

So I think what I need to do is have the signal thread pick up this message and enqueue the resize action in a threadpool worker that waits for the ConnectConsole. That would leave the signal thread free to go back around and notice the broken pipe on _GetData/ReadFile while making the resize signal queue up and wait politely until the initialization is ready without racing trickery by overwriting the launch arguments hopefully before the buffers were initialized.

@miniksa commented on GitHub (Jun 17, 2021): I think I see what is going on here. It looks like this code is attempting to quick change the startup size of the initial console allocation before another thread gets to allocating the buffer. But depending on the speed of things.... the buffer might have already been initialized. https://github.com/microsoft/terminal/blob/b3b648496e92d14e88bbede1b2c0b63e9d56b599/src/host/PtySignalInputThread.cpp#L96-L107 When I trace the code history back into 2018, before we went open source, this code was initially written to just call s_ResizeWindow always without the special early-case. But it looks like that had a few problems: 1. If the s_ResizeWindow goes off before most of the console buffers are set up, it runs into unexpected uninitialized situations. 2. If the signal thread blocks itself until everything else is ready... it's not able to detect when the handle/pipe is broken which is a shutdown indicator for ConPTY. So I think what I need to do is have the signal thread pick up this message and enqueue the resize action in a threadpool worker that waits for the ConnectConsole. That would leave the signal thread free to go back around and notice the broken pipe on _GetData/ReadFile while making the resize signal queue up and wait politely until the initialization is ready without racing trickery by overwriting the launch arguments *hopefully* before the buffers were initialized.
claunia commented 2026-01-31 04:03:40 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jun 18, 2021):

@o-sdn-o can you please try my proposed fix in #10449 and see if it resolves the issue for you? I was unable to confirm the problem on my work machine prior to the change even with your code variations to the sample above.

@miniksa commented on GitHub (Jun 18, 2021): @o-sdn-o can you please try my proposed fix in #10449 and see if it resolves the issue for you? I was unable to confirm the problem on my work machine prior to the change even with your code variations to the sample above.
claunia commented 2026-01-31 04:03:40 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 18, 2021):

@miniksa proposed fix in #10449 resolves the issue. Thank you 😀!

@o-sdn-o commented on GitHub (Jun 18, 2021): @miniksa proposed fix in #10449 resolves the issue. Thank you 😀!
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-Server Issue-Bug Priority-2 Product-Conpty Resolution-Fix-Committed
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#14201
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?