Push an error after awaiting a signal and unreference/free the object.

[Daylily-Zeleen]

Tested versions

v4.5.beta.custom_build [8a27aca]

System information

Windows 10 - v4.5.beta.custom_build [8a27aca]

Issue description

Await a signal and unreference the object will push an error like below:

E 0:00:08:111   test.gd:13 @ _ready(): Object '<Object#-9223372002830580334>' was freed or unreferenced while a signal is being emitted from it. Try connecting to the signal using 'CONNECT_DEFERRED' flag, or use queue_free() to free the object (if this object is a Node) to avoid this error and potential crashes.
  <C++ 源文件>     core\object\object.cpp:2272 @ Object::~Object()
  <栈追踪>         test.gd:13 @ _ready()

Steps to reproduce

Attach this script to a node and just run the scene.

extends Node2D

class Test:
	signal test(a: int)

	func _init() -> void:
		Engine.get_main_loop().create_timer(0.5).timeout.connect(test.emit.bind(10))


func _ready() -> void:
	var t := Test.new()
	var res := (await t.test) as int
	t = null
	print("Test： ", res)

Minimal reproduction project (MRP)

MRP.zip

[dalexeev]

This error tells you that the object was deleted while its own signal handler was executing (await coroutines are implemented with a one-shot signal handler, the rest of the _ready() function becomes a one-shot signal handler for t.test).

As far as I can tell, this is not supported behavior. All signal handlers are supposed to complete before the object is deleted.

You can try to work around the issue as suggested in the error text, or add await get_tree().process_frame before t = null.

[Daylily-Zeleen]

This is not occur in previous version, such as 4.4.1 stable.

You can see not any error in debugger.

---

Intuitively, signal emitting is finished after await is executed, delete the object should be safe.

[Daylily-Zeleen]

The point is not t = null, it just help us to catch the error that where it is occurred in script.
This error will occur event if we remove this line.

[dalexeev]

The point is not t = null, it just help us to catch the error that where it is occurred in script.
This error will occur event if we remove this line.

Yes, there is no difference here, because otherwise the local variable will be cleared at the end of the function.

Intuitively, signal emitting is finished after await is executed

No, the intuitive expectation here is wrong. The signal handler execution ends when the call is interrupted (reaches the end, return or await signal/coroutine). await get_tree().process_frame fixes the problem precisely by delaying the object dereferencing after the signal handler has completed.

delete the object should be safe

Maybe, if it really is a regression. Bisection is needed to determine the cause.

[precup]

Maybe, if it really is a regression. Bisection is needed to determine the cause.

Bisects to #105453.