VS2019: Extremely high memory usage with v3.4.1.21

[CookiePLMonster]

Please let me know if I do anything to provide more information about this bug. As it stands I don't know if I can e.g. force this extension to log anything for me.

Upgrading the GitExt VS2019 extension from v3.4.0.7 (the newest build on GitHub) to v3.4.1.21 (the newst build on VS Marketplace) seems to result in an extremely high memory usage of devenv.exe, circa 2GB for just the IDE loaded with no code! With a bigger solution loaded, devenv.exe easily crashes as it runs out of memory.

v3.4.0.7, IDE loaded with no code:

v3.4.1.21, IDE loaded with no code:

For all I know, it wasn't "always" like this as it seems to have worked fine for me until yesterday. To my knowledge I have not changed any settings, the last thing I did in VS before I noticed things started breaking was opening a CMake project via VS. Because I am not sure how to debug this, I do not know if this action had any relevance to the issue or not.

So far I observed this on VS16.11.2 and VS16.11.3.

[george-pearson]

Hey, I think it does log some unhandled exceptions to the Output window, do you have anything there? Example:

[CookiePLMonster]

Not when I open VS with no code, sadly. Only Qt VS plugin outputs anything when running the IDE like this, and I've verified it is not related to the issue at hand (in fact, I didn't even have this plugin installed at the time of reporting this issue).

[george-pearson]

Hmm I tried opening the main GitExtensions repo on VS 16.11.3 with and without the 3.4.1 extension installed and it seemed roughly about the same memory consumption on my machine and didn't crash 🤷‍♂️

I'm wondering if this is related to my NuGet update changes:

1. CommandBars update, https://github.com/gitextensions/gitextensions.vsix/pull/25
2. All other NuGet packages update, https://github.com/gitextensions/gitextensions.vsix/pull/26

I've made 3 test builds by reverting both of these changes and either one. If it wouldn't be too much trouble could you see if any of them fix the memory issue for you? test-builds.zip

[CookiePLMonster]

Hmm I tried opening the main GitExtensions repo on VS 16.11.3 with and without the 3.4.1 extension installed and it seemed roughly about the same memory consumption on my machine and didn't crash 🤷‍♂️

That doesn't surprise me, as this version of the extension worked fine for me for a long time, and then I must have did something to trigger the issue. I just can't pinpoint what exactly, the fact I started noticing it after opening a CMake project via VS is just my rough guess.

I tested the builds:

• revert-nugetupdates - no change, memory usage is at around 2GB
• revert-commandbars-update - seems fixed, memory usage is back to normal!
• revert-both - now this is weird - this build also results in high memory usage :/

Those results make no sense (unless the builds are mixed up), so after revert-both I went back to the revert-commandbars-update build to check it again - 3 out of 3 attempts the commandbars build works fine, whether I load VS with no project or open an existing project using git, memory usage stays at around 300MB.

Is there some sort of plugin settings or cache I could move out/wipe to see if it helps? I tried looking for something like this but didn't find any, and I'd like to avoid resetting all my VS settings (a Repair + restore settings didn't help).

[george-pearson]

Hmm yes that result doesn't make sense to me, wondering if I got them mixed up somehow... Have done another set: test-builds-2.zip

I don't think they get cached 😕 I found this article on the /ResetSkipPkgs devenv command line argument, but I think that's for stopping them from being "disabled" like you can see in the GUI.

[CookiePLMonster]

In the meantime, I compiled the extension myself and attempted to reproduce the issue from an experimental environment - but as expected, it doesn't reproduce there.

Then, I reversed the debugging scheme, and right now I'm using the experimental environment to debug my regular environment - this way the issue reproduces, and given that at the time of writing this post a Memory snapshot collected over 7 million roots, something seems to be leaking references severely.

If this collection ever finishes, I'll hopefully be able to at least pinpoint what is the data that is leaking.

[CookiePLMonster]

I finally managed to take a memory snapshot, here's the top results. Notice the presence of CommandBars there, which is in line with the revert fixing the issue! Now, if I manage to find what's the oustanding reference...

EDIT: Apparently cycle references are being detected, but not freed? I'm not well versed with C# but it looks like this to me.

[CookiePLMonster]

OK, last post in that tripleposting thread :)

I troubleshooted it further and seems like clearing out (i.e. return false;) the ChangeCommandCaption function (the only one to rely on CommandBars) reliably mitigates this issue. Do you reckon this points at CommandBars having some issue out of gitext's control? If that's the case, I imagine it'd be hard to escalate, given I cannot even figure out the correct repro steps :(

EDIT: The CommandBars NuGet package has several pre-release versions, tomorrow I'll check if any of them help: https://www.nuget.org/packages/Microsoft.VisualStudio.CommandBars/