[Bromeon]

During teardown, SceneTree frees objects while async tasks still await their signals. Freeing disconnects the resolver -> this marks the future Dead -> wakes -> deferred poll -> causes panic in SignalFuture::poll(). The panic is caught but spams errors on every exit.

The panicking poll fires after MainLoop de-init, but before the first level de-init hook. For Godot 4.5, we have no MainLoop hook, so we check SceneTree::get_root().

Closes #1624.

[GodotRust]

API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-1625

[Bromeon]

Thanks for the feedback! I refactored is_engine_exiting() multiple times, was indeed a bit messy.

I'm also not sure what signals can emit during shutdown, but in theory, if there are some signals that get emitted during shutdown, they would now get silently ignored as soon as ENGINE_EXITING is true.

That's true, do you think this is a problem in practice? What would you suggest? 🤔

[TitanNano]

That's true, do you think this is a problem in practice? What would you suggest? 🤔

This:

We will also drop all futures in cleanup() so we don't really have to clear the task here.

We eliminated the panic/error that is caused by the freed signal object during shutdown. So now any future that is being polled during shutdown is assumed to have a genuine reason to be polled. I think it's easier to handle future panics and issues that might come up instead of users having to figure out why their edge case is silently ignored.

[Bromeon]

I think it's easier to handle future panics and issues that might come up instead of users having to figure out why their edge case is silently ignored.

I think you're right about potentially legitimate use cases for tasks during shutdown. For example, awaiting a tree_exiting signal (which is emitted after MainLoop stage deinit, I just checked).

I changed the PR to no longer cancel the tasks on shutdown (but the guard in Drop stays). The Drop guard removes spurious panics (no UB) when the awaited object is freed under the parked task.

However, without the guard in poll_future(), we can run into actual UB (not just panics) in safeguard-disengaged mode. Without the early return in poll_future(), this happens:

• future.as_mut().poll(&mut ctx)
• Resumes user code after .await
• This user code can capture a Gd<Node> that was engine-freed during shutdown.
• User accesses the Gd -> use-after-free.

This even affects the awaited node itself: with deferred polling, the signal can fire (resolving the future) and the node is freed before the task actually resumes -> even the awaited Gd may be dangling by then.

Yes, safeguards-release-disengaged is explicitly allowed to cause UB, but typically this should only punish "wrong use" like calling free() twice. In this case it's the engine freeing the object, not the user.

So I wonder if this isn't surprising? Right now I also don't have a good solution apart from cancelling or introducing liveness-checks in disengaged mode.

[TitanNano]

Without the early return in poll_future(), this happens:

• future.as_mut().poll(&mut ctx)
• Resumes user code after .await
• This user code can capture a Gd that was engine-freed during shutdown.
• User accesses the Gd -> use-after-free.

But this is not exclusive to shutdown, right? A node could always be freed before a task is polled again.

[Bromeon]

But this is not exclusive to shutdown, right? A node could always be freed before a task is polled again.

Yes, but usually the causality is more direct: someone calls free() or queue_free(), unloads a scene, etc. Here it's a shutdown event, which can also be triggered externally (it's even possible that the user shutting down isn't the developer). Either way, it might be good to prepare for this by e.g. hooking into the on_stage_deinit callbacks.

But when running in safeguards-strict/-balanced modes, this will hopefully be detected before it ever gets to the "UB" situation.