isle-portable icon indicating copy to clipboard operation
isle-portable copied to clipboard

~ViewLODList(): Assertion `m_refCount == 0'

Open AJenbo opened this issue 7 months ago • 5 comments

This happens when shutting down the game. It's hard to know if the remaining leakage issues are related to it or not so probably a good place to start if anyone want to try and fix memory leakage.

isle: isle-portable/LEGO1/viewmanager/viewlodlist.h:209: virtual ViewLODList::~ViewLODList(): Assertion `m_refCount == 0' failed.
Aborted (core dumped)

AJenbo avatar May 19 '25 00:05 AJenbo

(happens in decomp too)

foxtacles avatar May 19 '25 01:05 foxtacles

Someone probably did a delete aViewLODList; instead of a aViewLODList->Release() (or equivalent). I will admit to being more knowledgeable of Objective-C, which uses reference counting on all non-singleton objects and direct calls to the destructor is considered a bad idea. Other than compiling for release (and thus ignoring the assert), fixing it should be trivial.

I know this project is currently trying to match the behavior of the original Lego Island as close as possible, so maybe this could be "fixed" in the next stage of the project?

MaddTheSane avatar May 27 '25 23:05 MaddTheSane

I really hope this project will fix bad stuff like that. We did already fix other bad dev assumptions in the code.

AJenbo avatar May 28 '25 00:05 AJenbo

We can fix bugs that aren't game altering in portable, but before doing so we should understand the complete nature of them. The assertion in this particular case seems reasonable, so we should figure out where the actual bug is and resolve that. (instead of just removing the assert, for instance)

foxtacles avatar May 28 '25 00:05 foxtacles

There appears to be another leak related to LegoROI. LegoROI adds a reference to a ViewLODList, and in certain circumstances (i.e. after having built the racecar, going back to the Infocenter, then existing through the green brick) a LegoROI is leaked somewhere which leads to a ViewLODList reference leak, which leads to this assertion.

Unfortunately the ownership model of LegoROI is very complicated so it's not obvious which component isn't cleaning up properly. Tracking this will require more digging and tracing of everything where LegoROI* is passed into (i.e. all LegoEntity instances)

foxtacles avatar Jul 20 '25 18:07 foxtacles