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

Memory leak and other issues when saving settings #14456

New Issue
Open
opened 2026-01-31 04:10:54 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 04:10:54 +00:00
Owner
Copy Link

Originally created by @mimvdb on GitHub (Jul 11, 2021).

Windows Terminal version (or Windows build number)

1.8.1521.0 (also observed on source build 2021-07-11)

Other Software

No response

Steps to reproduce

Open the settings dialog and spam click save. No option needs to be changed.

Video: 13 seconds in, the settings could not be reloaded from file (not sure if it is not loading or file corruption).
https://user-images.githubusercontent.com/2277504/125179830-a31f3a00-e1f2-11eb-8b6f-6f6aa07896c5.mp4

Expected Behavior

Memory stays roughly the same, settings file can be loaded after saving, main UI does not extend past its borders.

Actual Behavior

Memory grows and is not reclaimed, settings file can sometimes not be loaded after saving, UI grows past its borders during reloading.

(Second and third only discovered after deciding to record a video for the memory leak)

Not sure if you want separate tracking issues for these, let me know.

Originally created by @mimvdb on GitHub (Jul 11, 2021). ### Windows Terminal version (or Windows build number) 1.8.1521.0 (also observed on source build 2021-07-11) ### Other Software _No response_ ### Steps to reproduce Open the settings dialog and spam click save. No option needs to be changed. Video: 13 seconds in, the settings could not be reloaded from file (not sure if it is not loading or file corruption). https://user-images.githubusercontent.com/2277504/125179830-a31f3a00-e1f2-11eb-8b6f-6f6aa07896c5.mp4 ### Expected Behavior Memory stays roughly the same, settings file can be loaded after saving, main UI does not extend past its borders. ### Actual Behavior Memory grows and is not reclaimed, settings file can sometimes not be loaded after saving, UI grows past its borders during reloading. (Second and third only discovered after deciding to record a video for the memory leak) Not sure if you want separate tracking issues for these, let me know.
claunia commented 2026-01-31 04:10:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 12, 2021):

Not sure if you want separate tracking issues for these, let me know.

Typically, yea, we'd prefer separate issues, but since you've already got #10619 open for the overflow bit, we can just leave this open for the memory leak. I've got a strong suspicion that the memory leak and the "failed to load settings" dialog will end up with the same root cause ☺️

@zadjii-msft commented on GitHub (Jul 12, 2021): > Not sure if you want separate tracking issues for these, let me know. Typically, yea, we'd prefer separate issues, but since you've already got #10619 open for the overflow bit, we can just leave this open for the memory leak. I've got a strong suspicion that the memory leak and the "failed to load settings" dialog will end up with the same root cause ☺️
claunia commented 2026-01-31 04:10:55 +00:00
Author
Owner
Copy Link

@mimvdb commented on GitHub (Jul 13, 2021):

Unfortunately the question here seems to be what doesn't leak.

  • The settings.Copy() doesn't seem to leak 😄
  • Determining selectedItemTag

Besides that pretty much any interaction the MainPage::UpdateSettings has with the UI causes the growing memory as seen in the video. Some particulars:

  • Any call to _Navigate seems to leak, setting the CacheSize of the contentFrame to 0 doesn't help
  • Calls that manipulate the menuItems such as menuItems.ReplaceAll or Clear/Append leak even when the same elements are used
  • Calling ReplaceAll twice or Clear/Appending multiple times back to back causes a crash for some reason

I'm stopping my investigation here. Perhaps it is easier to debug with access to the Windows.UI.* source if the terminal team has access?

@mimvdb commented on GitHub (Jul 13, 2021): Unfortunately the question here seems to be what _doesn't_ leak. - The `settings.Copy()` doesn't seem to leak 😄 - Determining `selectedItemTag` Besides that pretty much any interaction the `MainPage::UpdateSettings` has with the UI causes the growing memory as seen in the video. Some particulars: - Any call to `_Navigate` seems to leak, setting the CacheSize of the contentFrame to 0 doesn't help - Calls that manipulate the `menuItems` such as `menuItems.ReplaceAll` or `Clear`/`Append` leak even when the same elements are used - Calling ReplaceAll twice or Clear/Appending multiple times back to back causes a crash for some reason I'm stopping my investigation here. Perhaps it is easier to debug with access to the Windows.UI.* source if the terminal team has access?
claunia commented 2026-01-31 04:10:55 +00:00
Author
Owner
Copy Link

@mimvdb commented on GitHub (Jul 16, 2021):

I couldn't resist taking another look. It seems the main (or only) issue is navigating the pages. (The menuItems.ReplaceAll might implicitly navigate, and calling it twice crashing might be an unrelated issue)

Interestingly, some pages leak way more than others. For example, on 1.8.1521.0, the "color schemes" page leaks hardly anything while the "actions" page seems to leak more than a megabyte per click on "discard".

A debug build on main shows "color schemes" also leaking, and makes the "actions" page leak about 5MB per navigation.

I'll file a separate issue for the settings file not loading, as that seems less related now.

@mimvdb commented on GitHub (Jul 16, 2021): I couldn't resist taking another look. It seems the main (or only) issue is navigating the pages. (The `menuItems.ReplaceAll` might implicitly navigate, and calling it twice crashing might be an unrelated issue) Interestingly, some pages leak way more than others. For example, on 1.8.1521.0, the "color schemes" page leaks hardly anything while the "actions" page seems to leak more than a megabyte per click on "discard". A debug build on main shows "color schemes" also leaking, and makes the "actions" page leak about 5MB per navigation. I'll file a separate issue for the settings file not loading, as that seems less related now.
claunia commented 2026-01-31 04:10:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 2, 2022):

Maybe related:

I could have sworn I saw another related issue yesterday, but I'm having a hard time finding it now

@zadjii-msft commented on GitHub (Feb 2, 2022): Maybe related: * https://github.com/microsoft/microsoft-ui-xaml/issues/5978 * https://github.com/microsoft/microsoft-ui-xaml/issues/1000 (but that was fixed in 2.2 so I doubt it's that) I could have sworn I saw another related issue yesterday, but I'm having a hard time finding it now
claunia commented 2026-01-31 04:10:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 16, 2022):

Okay, I've got a VS diag session in D:\dev\gh-10609\Report20220316-1134.diagsession. I'm not totally sure how to read this, so bear with me:

image
image

Looks like half of the 8MB that got allocated by saving the menu a few times were random ntdll allocations. The other half look like TermControls, so maybe we're accidentally leaking the preview controls somehow. Where are we taking a strong ref when it should be a weak...?

@zadjii-msft commented on GitHub (Mar 16, 2022): Okay, I've got a VS diag session in `D:\dev\gh-10609\Report20220316-1134.diagsession`. I'm not totally sure how to read this, so bear with me: ![image](https://user-images.githubusercontent.com/18356694/158643752-a2eacdeb-757d-42a5-bec6-ace0b4113768.png) ![image](https://user-images.githubusercontent.com/18356694/158643792-6c0b46e2-aad0-4d0c-8485-dd643a1bf704.png) Looks like half of the 8MB that got allocated by saving the menu a few times were random `ntdll` allocations. The other half look like `TermControl`s, so maybe we're accidentally leaking the preview controls somehow. Where are we taking a strong ref when it should be a weak...?
claunia commented 2026-01-31 04:10:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 16, 2022):

1005e0dfc makes this a bit better, but there's still some leakage. Here's the deal though - there's leakage even in the XAML Controls Gallery with the nav view.

@zadjii-msft commented on GitHub (Mar 16, 2022): 1005e0dfc makes this a bit better, but there's still some leakage. Here's the deal though - there's leakage even in the XAML Controls Gallery with the nav view.
claunia commented 2026-01-31 04:10:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 16, 2022):

image
So in this comparison, there was +3MB in DispatchMessageWorker, so I click on that frame, and then below that shows a bunch of RtlpAllocateHeapInternal calls, that all expando to point at Windows.UI.Xaml.dll. So, it's not us?

@zadjii-msft commented on GitHub (Mar 16, 2022): ![image](https://user-images.githubusercontent.com/18356694/158687093-ed9c82c3-ffe2-416a-b615-6f959e887e1f.png) So in this comparison, there was +3MB in `DispatchMessageWorker`, so I click on that frame, and then below that shows a bunch of `RtlpAllocateHeapInternal` calls, that all expando to point at `Windows.UI.Xaml.dll`. So, it's not us?
claunia commented 2026-01-31 04:10:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 16, 2022):

"D:\dev\gh-10609\Report20220316-1640 (2).diagsession" has two snapshots, both with +780KB on a single save of the SUI.

@zadjii-msft commented on GitHub (Mar 16, 2022): `"D:\dev\gh-10609\Report20220316-1640 (2).diagsession"` has two snapshots, both with +780KB on a single save of the SUI.
claunia commented 2026-01-31 04:10:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 9, 2024):

Seems like this is still present on 1.22 canary builds. Even after closing the SUI, the XAML objects remain leaked.

Amazingly enough, I think this might be fixed in WinUI 3. The WinUI 2 gallery repros this pretty readily, just switching pages in the NavView page. But the WinUI 3 gallery didn't seem to.

@zadjii-msft commented on GitHub (Jul 9, 2024): Seems like this is still present on 1.22 canary builds. Even after closing the SUI, the XAML objects remain leaked. Amazingly enough, I think this might be fixed in WinUI 3. The WinUI 2 gallery repros this pretty readily, just switching pages in the NavView page. But the WinUI 3 gallery didn't seem to.
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-SettingsUI External-Blocked-WinUI3 Help Wanted Issue-Bug Priority-1 Product-Terminal
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#14456
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?