Fix memory leak in MainlineVersionStrategy#4809
Conversation
- Remove ToArray() loop to prevent exponential array growth - Add caching to GetCommitsWasBranchedFrom to avoid redundant calculations - Fixes OOM kills on ADO agents with large repos
There was a problem hiding this comment.
Pull request overview
This PR addresses excessive memory usage (up to OOM) in MainlineVersionStrategy when calculating versions for large, branch-heavy repositories by removing a pathological list-growth pattern and introducing caching to reduce repeated computations.
Changes:
- Removed the
ToArray()-based loop that could repeatedly duplicate list entries (leading to explosive growth). - Added a cache for
GetCommitsWasBranchedFromresults to avoid redundantFindCommitBranchesBranchedFromcalls for the same branch/exclusion set.
src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
asbjornu
left a comment
There was a problem hiding this comment.
Awesome work! I've not verified your numbers, but I think MainlineVersionStrategy is well covered with tests, so as none of them breaks, this should at least not make the situation worse. I say it's worth getting this merged and into the hands of developers who've experienced GitVersion OOM.
|
@arturcic seems like a recurring problem now that PRs are halted in the
|
|
@sanelson mind to fix the minor sonacloud issue? |
might be after some changes to the rulesets I did |
Head branch was pushed to by a user without write access
|
@sanelson please revert the change, seems it was a false positive |
Sorry, I should have built locally before I committed that, lol. Changed it to use |
|
|
Thank you @sanelson for your contribution! |





Fixes
Description
Having memory leak issues with gitversion 6.3.x - 6.5.x. Runs fine locally (Ubuntu 24.04.3 LTS) but when running via an Azure DevOps agent (Ubuntu 22.04.5 LTS) against the same repo it quickly uses all memory on the agent and then the gitversion process is OOM killed.
Some stats on the repo which triggers this issue may be relevant for others having the same problem:
Note: I used Claude Sonnet 4.5 to assist with the issue analysis, code patch and test case creation.
Related Issue
Resolves #4418
Motivation and Context
How Has This Been Tested?
As a few others stated in #4418 I was unable to replicate this issue running locally. The severe memory leak only seemed to occur when running GitVersion from one of our custom Ubuntu ADO agents.
I created a sanitized version of our repository that I was going to share in this PR but the obfuscation process caused the issue to disappear and I was unable to replicate the memory leak with the sanitized repo. Instead I customized the ADO pipeline to show detailed information about the pre-patch memory leak. And a subsequent run with the patch applied with a comparison between the two.
Since I have not found a way to replicate the failure scenario outside of our very specific repo and ADO agent config it didn't make much sense for me to create a traditional test case for this change.
Here are the details from the most recent test pipeline run.
Memory Leak Failure Run Detail
Memory Leak Fix Run Detail
ADO Agent Test Environment Specs
Git config
Gitversion Config
Screenshots (if appropriate):
Checklist: