ObjectDB instances leaked at exit

[verillious]

Godot version: v3.2.3.stable.mono.official godot-console version: 3.1.3

OS/device: macOS 10.14.6, MacBook Pro (2017)

Issue description: When exiting a project with godot-console enabled, there are many ObjectDB instance leaks.

Steps to reproduce:

• Run godot in verbose mode
• Create new project
• Create main scene
• Install godot-console
• Activate godot-console in plugins menu
• Exit godot

Minimal reproduction project and log output: console_test.zip log_output.txt

[verillious]

I noticed this when doing a big refactor this weekend - I'm unsure if it's an issue with godot or godot-console but figured I'd let you know

[quentincaffeino]

Very strange, I don't have that issue.

I'll check later with the steps you've provided.

Could you please:

1. clone this repo (alt. pull, cause I just pushed changes where I added verbose flag)
2. run GODOT=godot_3.2.3-mono make run-demo where godot_3.2.3-mono path to your godot binary.
3. And post the output here

Thanks

[verillious]

Initially I simply made a fresh clone of this repo, ran the command and got this result:

• The demo project did not launch

Output from make: run_demo_log_output.txt Mono log for completeness: 2021_01_31 17.40.28 (2346).txt

---

After this I opened /godot/project.godot once in the editor and got the following warning:

Unable to load addon script from path: 'res://addons/gut/gut_plugin.gd' There seems to be an error in the code, please check the syntax.

I clicked OK on that, closed the editor and re-ran the command with the following result:

• The demo project launched correctly

Output from make: run_demo_log_output_02.txt Mono log for completeness: 2021_01_31 17.54.47 (2634).txt

[quentincaffeino]

Ok so I repeated your process from last message and I got the same result. I forgot about images with imports which are not committed to the repo, that's why it wasn't running the first time.

Also from what we can see with the both of those logs is that leak occurs only when engine exits with "panic".

Also I've tested the repro example you've provided, it works like a charm without leaks.

Could that be that you exit the process some "weird" way?

OS/device
OS: elementary OS 5.1.7 Hera x86_64 
Kernel: 5.9.10-050910-generic

[verillious]

Interesting - I don't do anything fancy (launch via terminal and exit by clicking x and confirming in the engine).

I just tested the same steps on my Windows 10 machine and managed to reproduce the issue. I wondered if it might be mono-specific or OSX-specific so I tested both mono and regular versions of Godot and reproduced it on both. I saved out the output: (start to finish, through starting the engine, installing godot-console, activating the plugin etc)

mono_windows_log.txt regular_windows_log.txt

[quentincaffeino]

You were right, I reproduced leak with the steps you've provided. Not sure how to fix it right now, but I'll definitely will. Thanks for reporting)

[verillious]

I'm glad you managed to - if you need any help verifying stuff on osx I'll be happy to! My suspicion is some kind of circular dependency issue. I've had problems in the past with preloaded stuff not being cleared up properly (I solved my issue by moving all preloads into one utility class and referencing them through that). But that's only a hunch.

[quentincaffeino]

Thank you, I will ping you as soon as I have something)

Moving every preload to one file is kinda impossible with future plans of mine for this project (having a modular structure). I'll try examining other possibilities if there are any. I know that GUT had the same problem before v7, so I will try to dig into their project history to find how they solved this problem.

[quentincaffeino]

So I finally got back to it and it seems that the error occurs even if you don't launch the game itself. It is sufficient to run the project in the editor, then close the editor and leak will appear. If I run the game directly or through the editor I see no leaks at the exit (except when I exit the editor then it's all back). So I wonder if godot editor does some optimization and loads autoload singetons event before game is ran to make game start faster and doesn't free them later.

(Tested on 3.2.3 and 3.3.2)

I tried doing anything inside _exit_tree but it's not called when I close the editor so I'm not sure how to free the memory.

[akoutsoulelos]

While looking up the code to better understand how to use the plugin, the editor notified me about an error on Condole.gd, mentioning that a cyclical reference was found regarding Command/CommandService.gd. That was the reason, I come here to see if there is a known bug; but the only reference to ... cyclical reference was in this post. So, I started the editor in verbose mode, and I got the same results as you, even without running the project: when exiting the editor there are leaked instances, resources still in use and orphan StringNames. The issue persisted even when I run the project. Funny thing is that suddenly the initial problem (cyclical reference) is completely gone, and no errors are shown... I'm using Godot 3.3.2 on a LinuxMint laptop.

[RcubDev]

Thank you, I will ping you as soon as I have something)

Moving every preload to one file is kinda impossible with future plans of mine for this project (having a modular structure). I'll try examining other possibilities if there are any. I know that GUT had the same problem before v7, so I will try to dig into their project history to find how they solved this problem.

This seems to be GUT's overview of memory management from 7.0: https://github.com/bitwes/Gut/wiki/Memory-Management

They have a nice writeup on memory management in godot (not specific to GUT) at the bottom. You might have already seen this though. Figured I'd pull it into the conversation though. I spent a few hours yesterday trying to resolve this issue. I seemed to be able to get rid of some of the leaks by changing several classes that were using const <name> = preload("path") to var <name> = load("path"). Note I couldn't change all of them without compile errors and I wasn't testing or running the tests all the time so take that for what it's worth. It seems a lot of plugins deal with these memory issues. It also seems they may not be fixed in 3.X anytime soon based on this thread: https://github.com/godotengine/godot/issues/21461. Though this might not be the exact issue as I believe there are memory leaks we can solve in the project. It seems odd to me that its loading anything from the plugin into memory without running the project considering the entire plugin is an autoload.

[quentincaffeino]

Thanks for investigating, @ryan-linehan, I've already seen that docs. Seems strange to me how is that godot has resources with reference counters but it cannot free them on exit.

Using loads instead of preloads is not a bad option. I used const preloads because initially I thought it would give better startup performance. But knowing where I want to head development of this project this wont help much and is not very possible with modular structure so we can try investigating this further.