Skip to content

[ZH] Fix RenderObjClass memory leaks in W3DPropBuffer #1319

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

xezon
Copy link

@xezon xezon commented Jul 20, 2025

This change fixes the RenderObjClass memory leaks in W3DPropBuffer. Is Zero Hour specific issue.

Tested by loading into Shell Map, into 1 Skirmish Map, and exit game. It would leak about 200 kb in this test.

Roughly the leaks marked with red are related to this

image

@xezon xezon added Minor Severity: Minor < Major < Critical < Blocker ZH Relates to Zero Hour Memory Is memory related Stability Concerns stability of the runtime labels Jul 20, 2025
@xezon xezon added this to the Stability fixes milestone Jul 20, 2025
@@ -119,7 +116,8 @@ W3DPropBuffer::W3DPropBuffer(void)
{
memset(this, sizeof(W3DPropBuffer), 0);
m_initialized = false;
clearAllProps();
m_numProps = 0;
m_numPropTypes = 0;
m_light = NEW_REF( LightClass, (LightClass::DIRECTIONAL) );

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m_numProps and m_numPropTypes are already set to zero in clearAllProps()

Copy link

@Mauller Mauller Jul 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They aren't initialised before this point, so since the loops were changed to use m_numPropTypes and m_numProps as their range, it could cause invalid behaviour as those variables have not been set yet.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replaced the call to clearAllProps() because there is nothing clear.

Technically even m_numProps = 0, m_numPropTypes = 0 are useless because of the memset(this, sizeof(W3DPropBuffer), 0); above, but nevermind that.

The constructor also sets m_initialized twice :D Nevermind the mess.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The memset doesn't do anything here btw (0 parameter size).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh lol.

Copy link

@Mauller Mauller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, my original fix for this also initialised all of the available slots into a known state.
But looks like it's not that much of an issue with how the add and remove functions work overall.

@Caball009
Copy link

Since you're refactoring the constructor of W3DPropBuffer anyway, maybe you want to tackle that bit from #942

@xezon
Copy link
Author

xezon commented Jul 20, 2025

Is ok, can be separate change.

@xezon xezon merged commit 94b99a7 into TheSuperHackers:main Jul 20, 2025
10 checks passed
@xezon xezon deleted the xezon/fix-w3dpropbuffer-memory-leak branch July 20, 2025 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Memory Is memory related Minor Severity: Minor < Major < Critical < Blocker Stability Concerns stability of the runtime ZH Relates to Zero Hour
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants