8000 ~ViewLODList(): Assertion `m_refCount == 0' · Issue #119 · isledecomp/isle-portable · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

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

Open
AJenbo opened this issue May 19, 2025 · 4 comments
Open

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

AJenbo opened this issue May 19, 2025 · 4 comments

Comments

@AJenbo
Copy link
Collaborator
AJenbo commented May 19, 2025

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)

@foxtacles
Copy link
Member

(happens in decomp too)

@MaddTheSane
Copy link

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?

@AJenbo
Copy link
Collaborator Author
AJenbo commented May 28, 2025

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

@foxtacles
Copy link
Member
foxtacles commented May 28, 2025

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0