Terminal: Opening/Closing tabs causes exit / blocked UI thread

[richardszalay]

NOTE: This is different from, but may be related to, #2230

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.175]
Windows Terminal version: 0.3.2142.0

Steps to reproduce

1. Open a new Windows Terminal instance
2. Open a second tab using either the "+" button
3. Close the new tab using CTRL+W, middle clicking the tab, or clicking the tab's "x"

Repeat steps 2-3 as fast as possible.

Expected behavior

Tabs continue to open and close.

Actual behavior

PowerShell - Most of the time, WT stops responding and interacting with it shows the "WindowsTerminal.exe is not responding" modal

CMD / WSL - WT stops responding for about 1 second and then exits (also happens for PowerShell sometimes)

[zadjii-msft]

Yea this is pretty trivially repro-able. I got it with a quick click on the new tab followed by immediately middle clicking. Thanks for the report!

[DoctorLogiq]

I'm getting the same issues without middle-click - for me it it becomes unresponsive when I open WindowsTerminal and click the dropdown menu to open a Command Prompt-style tab, then close the Powershell tab fairly quickly.

[richardszalay]

I managed to repro this with a debugger attached and it's the blocked at the same point as #2433 (_hJob.Reset() in ConhostConnection::Close()), so resolve the underlying issue should fix both issues.

[richardszalay]

(when someone tackles this, can they explain to me the purpose of _hJob? It doesn't appear to be used anywhere except to reset it, and I didn't think that operation blocked.)

[DHowett-MSFT]

I’m surprised that it’s still there, actually. We removed most (?) of it with a recent pull request.

It existed to make sure the console host was torn down (hard!) when a tab was closed, but that was causing powershell to crash because its console was torn down. If we aren’t initializing the job object, it’s not doing anything on reset. The hang could be on the line above it, though, especially if that line is a WaitForSingleObject.

[richardszalay]

Thanks for the summary. You're right, I can comment out that line and still repro the hang so it must be the line above: WaitForSingleObject(_piConhost.hProcess, INFINITE)

[xerdink]

I can confirm that it still exists on latest release with Windows 10 Build 18362.

[richardszalay]

This still reproduces in 0.4.2382.0, so I'm guessing it's unrelated to #2198

I now reproduce it by rapidly splitting and closing panes using keyboard bindings (split x 3, close x 3, repeat).

[zadjii-msft]

Playing with this for a few minutes, I got a crash here:

[0x1]   TerminalControl!winrt::Microsoft::Terminal::TerminalControl::implementation::TermControl::_ScrollbarUpdater + 0x14   
[0x2]   TerminalControl!winrt::Microsoft::Terminal::TerminalControl::implementation::TermControl::_TerminalScrollPositionChanged::__l2::<lambda_d4673cfb40ab3bbddd63d78386fc20ac>::operator() + 0x43   
[0x3]   TerminalControl!winrt::impl::delegate<winrt::Windows::UI::Core::DispatchedHandler,<lambda_d4673cfb40ab3bbddd63d78386fc20ac> >::Invoke + 0x5c   

Apparently updating the scrollbar? I'll try debugging with a actual Debug build next so I can get more details

[xobs]

I see different behavior -- it's closing itself when using the interface (e.g. using wget), not when exiting a terminal.

Note that processes continue to run after Terminal has closed, sometimes for weeks at a time. I have a gtkwave session that's been running for three weeks after its original Terminal closed itself.

[utybo]

This is still an issue on the latest release, middle clicking to quickly close tabs makes the entire terminal app crash

[zadjii-msft]

@utybo yep, hence why the issue is still open. We'll close the issue once a fix has been found and a PR with that fix has been merged 😜

[zadjii-msft]

From @Treit in #2947

Environment

Windows build number: 10.0.18975.0
Windows Terminal version: 0.5.2622.0

Steps to reproduce

1. Run wt.exe to start an instance of Windows Terminal

2. Press Ctrl-t 4 or 5 times to open a few tabs (running PowerShell)

3. In each tab, run `dir c:\ -rec`

4. Wait a few seconds, then click the 'x' on one of the tabs to close it while it is writing text to the console

Expected behavior

The tab closes.

Actual behavior

The terminal crashes with an Access Violation due to a null pointer dereference in TerminalControl!winrt::impl::consume_Windows_UI_Xaml_Controls_Primitives_IRangeBase<winrt::Windows::UI::Xaml::Controls::Primitives::ScrollBar>::Maximum

Notes

I can reproduce this consistently. Let me know if you would like a memory dump.

Here is a link to the feedback issue I opened:
https://aka.ms/AA65up1

Call stack

rax=0000d0e9f60fae3a rbx=00000000000002d6 rcx=0000000000000000
rdx=0000000000000000 rsi=00000000000002d6 rdi=000000000000001c
rip=00007ffd75b073d1 rsp=00000095845ff250 rbp=000001afa9234f70
 r8=0000000010000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000246 r12=0000000000000000 r13=000000000000001c
r14=00007ffda8394d10 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
TerminalControl!winrt::impl::consume_Windows_UI_Xaml_Controls_Primitives_IRangeBase<winrt::Windows::UI::Xaml::Controls::Primitives::ScrollBar>::Maximum+0x51:
00007ffd`75b073d1 488b01          mov     rax,qword ptr [rcx] ds:00000000`00000000=????????????????

 Child-SP          RetAddr           Call Site
00 00000095`845ff250 00007ffd`75b1812c TerminalControl!winrt::impl::consume_Windows_UI_Xaml_Controls_Primitives_IRangeBase<winrt::Windows::UI::Xaml::Controls::Primitives::ScrollBar>::Maximum+0x51 [E:\BA\35\s\src\cascadia\TerminalControl\Generated Files\winrt\Windows.UI.Xaml.Controls.Primitives.h @ 2838] 
01 (Inline Function) --------`-------- TerminalControl!winrt::Microsoft::Terminal::TerminalControl::implementation::TermControl::_ScrollbarUpdater+0x14 [E:\BA\35\s\src\cascadia\TerminalControl\TermControl.cpp @ 1373] 
02 (Inline Function) --------`-------- TerminalControl!winrt::Microsoft::Terminal::TerminalControl::implementation::TermControl::_TerminalScrollPositionChanged::__l2::<lambda_d4673cfb40ab3bbddd63d78386fc20ac>::operator()+0x43 [E:\BA\35\s\src\cascadia\TerminalControl\TermControl.cpp @ 1396] 
03 00000095`845ff2c0 00007ffd`9f91c471 TerminalControl!winrt::impl::delegate<winrt::Windows::UI::Core::DispatchedHandler,<lambda_d4673cfb40ab3bbddd63d78386fc20ac> >::Invoke+0x5c [E:\BA\35\s\src\cascadia\TerminalControl\Generated Files\winrt\windows.ui.core.h @ 1275] 
04 (Inline Function) --------`-------- Windows_UI!Windows::UI::Core::CDispatcher::EnqueueAsyncWork::__l16::<lambda_59517943c03487243f9bea31c6c1a784>::operator()+0x67 [onecoreuap\windows\advcore\winrt\onecoreiwindow\corewindow\common\dispatcher.cpp @ 908] 
05 00000095`845ff310 00007ffd`a8394d26 Windows_UI!Microsoft::WRL::Details::DelegateArgTraits<long (__cdecl Windows::System::IDispatcherQueueHandler::*)(void)>::DelegateInvokeHelper<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<2>,Windows::System::IDispatcherQueueHandler,Microsoft::WRL::FtmBase>,<lambda_59517943c03487243f9bea31c6c1a784>,-1>::Invoke+0x71 [onecore\external\sdk\inc\wrl\event.h @ 245] 
06 00000095`845ff340 00007ffd`a836423b CoreMessaging!Windows::System::DispatcherQueue::DeferInvokeCallback+0x16 [mincore\coreui\dev\dispatcherqueue\WrtDispatcherQueue.cpp @ 893] 
07 00000095`845ff370 00007ffd`a8361d64 CoreMessaging!Microsoft__CoreUI__Dispatch__TimeoutHandler$CallbackThunk+0x11b [temp\42829c929effddb13f17f63c5ec49c58\Common__DllInterop.cpp @ 505] 
08 (Inline Function) --------`-------- CoreMessaging!System::Action::Invoke+0x1a [mincore\cn\cnruntime\lib\fullstr\fre\objfre\amd64\CnRuntime\Common__Delegate.cpp @ 91] 
09 00000095`845ff3f0 00007ffd`a83616fe CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCall::Callback_Dispatch+0x2c4 [mincore\CoreUI\Dev\System\Dispatch\DeferredCall.cs @ 62] 
0a 00000095`845ff4b0 00007ffd`a8368d1a CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCallDispatcher::Callback_OnDispatch+0x15e [mincore\CoreUI\Dev\System\Dispatch\DeferredCallDispatcher.cs @ 337] 
0b (Inline Function) --------`-------- CoreMessaging!Microsoft::CoreUI::Dispatch::Dispatcher::DispatchNextItem+0x685 [mincore\CoreUI\Dev\System\Dispatch\Dispatcher.cs @ 892] 
0c (Inline Function) --------`-------- CoreMessaging!Microsoft::CoreUI::Dispatch::Dispatcher::Callback_DispatchLoop+0x7d7 [mincore\CoreUI\Dev\System\Dispatch\Dispatcher.cs @ 465] 
0d 00000095`845ff520 00007ffd`a8367df6 CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0xada [mincore\CoreUI\Dev\System\Dispatch\EventLoop.cs @ 779] 
0e (Inline Function) --------`-------- CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapterBase::DrainCoreMessagingQueue+0x143 [mincore\CoreUI\Dev\System\Dispatch\UserAdapterBase.cs @ 674] 
0f 00000095`845ff640 00007ffd`a83668d1 CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch+0x1d6 [mincore\CoreUI\Dev\System\Dispatch\minwin\UserAdapter.cs @ 224] 
10 (Inline Function) --------`-------- CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatchRaw+0x9c [mincore\CoreUI\Dev\System\Dispatch\minwin\UserAdapter.cs @ 153] 
11 00000095`845ff730 00007ffd`a83666f3 CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter_DoWork+0xf1 [mincore\CoreUI\Dev\System\Dispatch\minwin\UserAdapterN.cpp @ 424] 
12 00000095`845ff810 00007ffd`ac99f903 CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc+0xa3 [mincore\CoreUI\Dev\System\Dispatch\minwin\UserAdapterN.cpp @ 659] 
13 00000095`845ff890 00007ffd`ac99f2ac USER32!UserCallWinProcCheckWow+0x4e3 [clientcore\windows\core\ntuser\client\clmsg.cxx @ 279] 
14 00000095`845ffa20 00007ffd`ac9b4543 USER32!DispatchClientMessage+0x9c [clientcore\windows\core\ntuser\client\daytona\objfre\amd64\client.cxx @ 3444] 
15 00000095`845ffa80 00007ffd`add30664 USER32!__fnDWORD+0x33 [onecoreuap\internal\windows\inc\ntuser\inc\ntcb.h @ 1214] 
16 00000095`845ffae0 00007ffd`abc01104 ntdll!KiUserCallbackDispatcherContinue [minkernel\ntos\rtl\amd64\trampoln.asm @ 601] 
17 00000095`845ffb68 00007ffd`ac9b54ee win32u!ZwUserGetMessage+0x14 [onecoreuap\windows\core\umode\moderncore\objfre\amd64\usrstubs.asm @ 190] 
18 00000095`845ffb70 00007ff7`3bbe46c6 USER32!GetMessageW+0x2e [onecoreuap\internal\windows\inc\private\core\ntuser\client\ntcftxt.h @ 538] 
19 00000095`845ffbd0 00007ff7`3bbecc42 WindowsTerminal!wWinMain+0x1c6 [E:\BA\35\s\src\cascadia\WindowsTerminal\main.cpp @ 150] 
1a (Inline Function) --------`-------- WindowsTerminal!invoke_main+0x21 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
1b 00000095`845ffce0 00007ffd`aced7034 WindowsTerminal!__scrt_common_main_seh+0x106 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
1c 00000095`845ffd20 00007ffd`adcfb1b1 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 
1d 00000095`845ffd50 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] 

[DHowett-MSFT]

This may have been fixed with #3835 (h/t to @mkitzan!)

[DHowett-MSFT]

(and that was released in v0.7.3415.0 yesterday/today.)