Closed Adrianilloo closed 1 year ago
It turns out that, while my fix solved a potential memory leak (by design), the apparent one I observed in my server (as reflected in the SM handles dump comparison screenshot) wasn't related and not even a memory leak. It was just the recent map list array (g_hArrayRecentMaps
) increasing on map change, as of normal functioning.
Nevertheless, this PR indeed fixes a memory leak if the user had a custom configuration like this due to the "brute force" KV loop approach, on a List type:
"List type vote"
{
"type" "list"
"vote" "1"
"Options"
{
"Option 1" "1" // g_hArrayVoteOptionName[iVote] = CreateArray(16);
"Option 2" "2"
}
"Options2" // Now ignored as of this PR
{
"Option 1" "1" // g_hArrayVoteOptionName[iVote] = CreateArray(16); -> LEAK (iVote = old iVote)
"Option 2" "2"
}
Hi,
Previous contributor here (fixed past memory leaks). I have casually found there were other leaks, still, arising every map change.
This PR fixes a memory leak at config parsing for List votes, as the code was pushing array strings in the wrong scope (a search loop).
The commit also enhances same parsing as the code located the assumed "Options" section in a brute force way (inadequately). Now it searches for the exact "Options" key for adding the List vote options.
Here you can see a SM Handles dump difference (using this viewer), after running a HL2DM server for nearly 6 days, at ~15 minutes average per map: