Slow memory leak in Windows Terminal

[Treit]

Windows Terminal version

1.16.3464.0

Windows build number

10.0.25272.0

Other Software

There appears to be a slow memory leak in Windows Terminal.

I was running my small Terminal Stress app that I have used to find other bugs in the past. I accidentally left it running overnight and when I came in the next morning I found WindowsTerminal was consuming a large amount of memory.

This appears to be reproducible by simply running the Terminal Stress app (a simple .NET console application) and letting it run.

Steps to reproduce

1. Build Terminal Stress and run it from a terminal window.

2. Let it run for a long time.

3. Observe that the memory usage for Windows Terminal climbs slowly.

4. Eventually stop the program from running.

5. Note that the memory usage (commit size) remains high.

Expected Behavior

Memory usage should remain relatively flat as the test program simply prints random characters to random positions on the screen.

Actual Behavior

The memory increases, quite slowly but surely.

In my most recent case I found the memory usage was more than 3GB after the stress program had run for about 20 hours.

[aqc-carlodri]

I'm stumbling into a very similar issue, I have some applications running inside Windows Terminal and a see a very slow but steady increase in memory usage

[HaroldStruwig]

I also experienced this - unusable for me until fixed - normal powershell does not have this issue

[zadjii-msft]

Guh, my debugging tools are proving pretty useless. Me testing on 1.16, with atlas disabled:

Of the 5300 allocations, 2000 were attributed to useless nvwgf frames.

A bunch more in d2d1:

Presumably that's all due to the DxEngine being enabled, not the Atlas engine. I wonder if Atlas has the same issue...

---

There also were a smaller number of allocations in the path for CodepointWidthDetector::_lookupGlyphWidthWithCache. That kinda makes sense - we're allocating new cache entries for the glyph widths. TerminalStress just generates random codepoints, so it kinda makes sense that would grow the cache size. That would be pretty slow I'd imagine...

[zadjii-msft]

With atlas enabled:

The other 3000 allocations are in the same CodepointWidthDetector::_lookupGlyphWidthWithCache frame.

I wonder if this just goes away with Atlas v3 (@lhecker)? Methinks this might just be the "we never resize the texture back down" in the OG atlas engine. So as TerminalStress just keeps on blatting new codepoints at the engine, we keep growing, and growing..... and never shrink it.

[lhecker]

At the default font size on a 4K display you get an upper bound of pretty much exactly 3000 glyphs in the texture atlas of the text renderer. Beyond that I don't really see a persistent memory growth, but I get the feeling that we might be seeing the effects of severe memory fragmentation because the LRU hashmap in AtlasEngine v1 is crudely built around a linked lists where each item is heap allocated. With TerminalStress we get up to hundreds of thousands of such allocations per second.

[dglee42]

I've had this memory leak problem in Terminal for months on a fully updated (OS and Store apps) Windows 10 Dell. I routinely run a WSL tab and one or two cmd+ssh tabs, but the problem occurs even with just one active tab.

Perhaps interesting though: I use a screen reader, being a blind Windows user. I usually use JAWS (https://www.freedomscientific.com) but have also used NVDA and Narrator. Experiments today seem to indicate, though not solidly yet, that the Terminal expansion is fastest with JAWS, next slower with Narrator, and slowest with NVDA. This makes me wonder if there's a relationship between the memory leak and support for assistive technology for blind users. The relative infrequency of complaints I see about this leak, coupled with the popularity of Terminal and my complete lack of success preventing the expansion, also makes me wonder this.

It is very uncommon for me to go a full day of Terminal use without my Terminal instance needing a restart because of its size exceeding 1 or 1.5 gig of memory.

Unfortunately, it would likely be hard for me to provide a memory dump because I process many things in terminal windows that might be considered private (mail, development projects, research, etc.).

[zadjii-msft]

This might just be fixed in 1.18. @lhecker double check me?

[lhecker]

Yeah, the memory allocations in the new AtlasEngine are much much simpler. It can still grow fairly large when you have a 500x200 terminal with 100k unique glyphs, but it's much less likely to leak now. There'll be more improvements in 1.20 on top of that (https://github.com/microsoft/terminal/tree/dev/lhecker/atlasengine-cleanup-drawglyph).

[HaroldStruwig]

This might just be fixed in 1.18. @lhecker double check me?

Any idea when 1.18 will be released as latest stable version?

[zadjii-msft]

Any idea when 1.18 will be released as latest stable version

Probably later this month, though, preview builds are usually quite stable too (if this is affecting you acutely)

[lhecker]

I can't reproduce a leak in either 1.17.12191.0 or 1.19.2412.0 after letting it run for about 1h, but the memory usage both fluctuates and rises much faster in 1.17 compared to 1.18/1.19 with the new renderer.

Probably fixed in at least 1.18? I'll close it for now. It's difficult to be certain about this though without a consistent/immediate repro. 😥