Windows terminal hangs after running ripgrep in a loop

[Treit]

Environment

Windows version 1903 OS build 18899.1000
Windows Terminal (Preview) version 0.2.1703.0

Any other software?
ripgrep 11.0.0

Steps to reproduce

Install ripgrep
Open wt (Windows Terminal), running PowerShell.
Run the following from the root of a large drive
while ($true) { rg -i "foo" }

Expected behavior

The terminal continually runs ripgrep against all files on the drive

Actual behavior

The terminal eventually hangs and is completely unresponsive.

The call stack for the main thread when the window hangs is attached.

HungTerminal1.callstack.txt

A minidump of the hung process is available here:
HungWindowsTerminal

[miniksa]

The callstack and dump given appears to be in a state of appropriate locks with output being written to the buffer at the time of the dump/stack break.

I'm trying to repro this locally to see if I can find something a bit more obvious.

[Treit]

The callstack and dump given appears to be in a state of appropriate locks with output being written to the buffer at the time of the dump/stack break.

I'm trying to repro this locally to see if I can find something a bit more obvious.

@miniksa I was able to reproduce it just now on my primary machine so if there is anything I can do to help debug it please let me know.

[Treit]

@miniksa Just adding some of the details I sent in email here for reference.

The issue I am hitting appears to be an infinite loop in:

void Terminal::_WriteBuffer(const std::wstring_view& stringView)

This is in Terminal.cpp, line 326

On line 372 we have the following code:

i += cellDistance - 1;

I can see in the debugger when this hang reproduces that cellDistance has become 0. Thus, this becomes a decrement instead of an increment.

So, the variable is decremented by one on line 372 and is then incremented by one at the start of the next loop iteration. When it comes back to line 372, i is decremented again, and this process repeats forever.

Further investigation will be needed to determine how cellDistance can become zero and trigger this infinite loop.

[Treit]

I have found an easier way to reproduce this issue, by running the following trivial C# program:

namespace TerminalStress
{
    using System;
    using System.Text;

    class Program
    {
        static void Main(string[] args)
        {
            Random r = new Random();

            Console.OutputEncoding = Encoding.UTF8;

            while (true)
            {
                char c = (char)r.Next(0xD100, 0xFA95);

                Console.Write(c);
            }
        }
    }
}

[miniksa]

Two issues here:

1. When something inside Terminal::_WriteBuffer, the function that sorely needs to be rewritten in the Boogaloo Bug Implement stream writing mechanism on buffer (a.k.a. WriteCharsLegacy2ElectricBoogaloo) #780, gets the cursor into an X position that falls outside the bounds of the buffer (Cursor X = 120, but the buffer is only valid 0-119), then the TextBuffer::Write methods will refuse to write because they're checking that the cursor is in bounds before attempting to write. This results in a cell-advance count of 0 reported to _WriteBuffer. It doesn't compensate for this in any appreciable manner. It also never realizes that proposedCursorPosition is outside the bounds of the buffer to correct itself down a line (X=0; Y++). Compensating for a 0 cell distance advance, a proposedCursorPosition.X past the buffer end, or both does resolve this issue.

2. However, something in Write is permitting a cell distance that when advanced by the caller results in a position outside the buffer. That's not correct. That's a character bisect (where we only end up drawing the left half of a wide character). I haven't totally narrowed this one down yet, but I'm looking into it next as it's important to fix this too.

All of this really comes down to.... #780 needs to get done. It would head off this entire class of issue. I'll patch up Terminal::_WriteBuffer now and #780 is booked for November.

[DHowett-MSFT]

Reopening: the cure was worse than the disease, so we may well just have to wait for #780 to land here. Sorry!

[ghost]

🎉This issue was addressed in #2924, which has now been successfully released as Windows Terminal Preview v0.6.2951.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #4150, which has now been successfully released as Windows Terminal Preview v0.8.10261.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #4150, which has now been successfully released as Windows Terminal Preview v0.9.433.0.:tada:

Handy links:

• Release Notes
• Store Download