Godot - Memory leakage in addon #57
Labels
Comments
|
The full output: |
|
This is probably an upstream bug with global scripts. |
|
Any movement on fixing the memory leaks? |
|
@JohnCWakley I think at the time we determined it was a misrepresentation in the leak detection in the Godot engine. It's been a while since we looked at it. Have you seen a similar report of output with global scripts in the latest Godot engine? |
|
@novabyte Yes, in Godot v3.3.2.stable.official, I am seeing the memory leaks for Reference inherited classes from Nakama: I have contributed code to the Godot project, when I get some time, I will investigate the leak detection and see if there are any potential issues to fix... |
|
I just re-tested the steps to reproduce using Godot 3.4.3, both with the version currently in the asset library as well as the current 'master' branch, and, unfortunately, I'm still seeing the output about leaked instances and orphaned string names. |
|
any news on this ? |
|
I'm not completely certain of this, but it looks like the common issue in Godot - the one @novabyte mentioned. In my experience, generally speaking , this can be ignored - it will happen most times you have an autoload, due to timing when the autoloads are unloaded and when the game officially "shuts down" (since autoloads are static, they must remain in memory for the duration of the app run, at least in my head!). |
|
Yeah, the last time someone investigated this in-depth, it was concluded to be a "false positive", ie Godot's memory leak detection incorrectly flagging these as memory leaks. It'd be great to dig into it again and somehow prevent that, but it's not a high priority |
|
Some additional observations I've made:
Even if I queue_free that node almost immediately upon startup, the memory leak related messages still occurs around program termination, suggesting this issue does not depend on Godot's autoload mechanism. Searching around raises my suspicion that this might have something to do with type dependency resolution. |
|
After a bit of surgery, I have determined the immediate cause of this error. The assorted internal classes defined in NakamaAPI.gd and NakamaRTAPI.gd which extend NakamaAsyncResult feature a static method called create which is static typed to return an object matching its class--a factory method. Here is an example: From my experience, I was surprised that this code did not fail parsing, as in Godot 3, classes cannot self class reference. Interestingly enough, just removing the Going through both files and stripping the "as" casting resolves this issue. I tested Godot 3.6-beta4 and the problem still exists. I tested Godot 4.2-stable and the problem does not exist. Additionally, all forms of self class referencing that I could think of were all possible. Because cyclical class references are supported in Godot 4 but more or less intentionally not in Godot 3, this issue is technically not a Godot bug. If it were to be addressed in Godot 3, I would suspect it would simply fail parsing, just as this code does: And an alternate Nakama implementation would be required, such as the adjustment I mentioned or perhaps the use of separate factory classes over static methods. I'll draft up a pull request to target the Godot 3 branch. |
|
Thank you for the detailed debugging @puzzud it would be great to have a pull request to review 🙏 |
puzzud
added a commit
to puzzud/nakama-godot
that referenced
this issue
Feb 29, 2024
lugehorsam
pushed a commit
that referenced
this issue
Feb 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When adding the Nakama autoload singleton and running/exiting the game (without accessing any of Nakama's functionalities), the console reports memory leakage.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: