Skip to content

Conversation

@Ivorforce
Copy link
Member

@Ivorforce Ivorforce commented Jan 9, 2026

Currently, GDCLASS owned GDType objects are never torn down. This leads to "unclaimed StringName" warnings at engine shutdown (when --verbose is used). This PR fixes this by tearing down these GDType instances at shutdown.

Explanation

Every compile time Object subclass (GDCLASS) statically owns a GDType *. This is allocated and initialized lazily on get_gdtype_static access.
Because of engine launch order, these GDType aren't immediately (or even necessarily) registered in ClassDB. The types are only registered when GDREGISTER_CLASS (or an alternative) is called, or when the first instance is created.

Practically, this means there may be any number of GDType instances hanging around that are not registered in ClassDB. To easily clean them up, I simply added an autorelease pool to ClassDB.
In the future, we might consider keeping a closer eye on static GDType (for example, by requiring explicit GDREGISTER_CLASS calls for every type, or by only creating them on explicit register), which would eliminate the need for this autorelease pool.

@Ivorforce Ivorforce added this to the 4.6 milestone Jan 9, 2026
@Ivorforce Ivorforce requested a review from dsnopek January 9, 2026 12:54
@Ivorforce Ivorforce requested a review from a team as a code owner January 9, 2026 12:54
This fixes "unclaimed StringName" warnings and improves engine shutdown correctness.

for (GDType **type : gdtype_autorelease_pool) {
if (!type) {
WARN_PRINT("GDType in autorelease pool was cleaned up before being auto-released. Ignoring.");
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
WARN_PRINT("GDType in autorelease pool was cleaned up before being auto-released. Ignoring.");
WARN_PRINT_ONCE("GDType in autorelease pool was cleaned up before being auto-released. Ignoring.");

I'd say, as it doesn't contain any details it'll be noisy if it floods with many of these

Copy link
Member Author

Choose a reason for hiding this comment

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

The warning isn't expected to ever print anyway, it's just a precaution for misuse. With multiple prints it would at least be possible to estimate how many GDTypes are affected.

Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest replacing it with a counter in that case to make it less noisy

Copy link
Contributor

Choose a reason for hiding this comment

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

If this is meant to be an impossible scenario, wouldn't DEV_ASSERT be preferable?

Copy link
Member Author

Choose a reason for hiding this comment

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

I would have agreed a year ago, but since working on Godot more I've grown more into the "don't crash if it's not fatal" mindset, at least for Godot. Warnings should be plenty to find the situation if it ever does arise.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd argue that's only relevant when something's directly accessible by the end-user. But we don't clearly define if internals should be handled to a different standard, so I digress

Copy link
Contributor

Choose a reason for hiding this comment

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

It could always be DEV_CHECK_ONCE() if the goal is to keep this out of normal builds? I'm not sure it matters too much in this particular case, though

Copy link
Contributor

@dsnopek dsnopek left a comment

Choose a reason for hiding this comment

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

Thanks! This seems fine to me :-)

Between WARN_PRINT() and WARN_PRINT_ONCE(), I'd personally probably also lean towards WARN_PRINT_ONCE() - but it probably won't end up really mattering in this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flood of Orphan StringName errors

4 participants