Editor Freezes and Can't Reopen Project If a Thread Never Finishes In a @tool Script

[A-Totally-Normal-Name]

Godot version

4.1.1.stable

System information

Windows 10 - Vulkan (Compatibility) - NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.3623) - AMD Ryzen 5 2600 Six-Core Processor (12 Threads)

Issue description

On a @tool script, if you have a thread running and you put thread.wait_to_finish() in the _exit_tree() function, but then never actually make the thread stop, the editor will simply freeze when you try to exit the scene (because its waiting for the thread to finish, which it never will).

The fix is obvious: change your script so that the thread actually finishes. However, because the error is in a tool script, Godot will freeze each time you try to reopen the project.

Instead, you have to manually open the script file and comment out the @tool line.

The reason the Engine initially freezes is clear but having it freeze each time you try to reenter the project with the @tool script in it is not as clear and seems like a bug.

Steps to reproduce

You can paste this script into any node (the commented out lines fix the freezing):

@tool
extends Node

var thread := Thread.new()
var semaphore := Semaphore.new()

#var exiting_tree : bool = false

func _ready() -> void:
    thread.start(thread_loop)

func thread_loop() -> void:
    while true:
        semaphore.wait()
        #if exiting_tree:
	    #return 

func _exit_tree():
    #exiting_tree = true
    #semaphore.post()
    thread.wait_to_finish() # Thread will never actually finish.

Now try to exit a scene with this script running in it. Godot should freeze.
Try to reenter the project with this script running in it. Godot should freeze.

Minimal reproduction project

N/A

[jsjtxietian]

The implentation of Thread::wait_to_finish is quite straight forward and after some check just calls thread.join().

I suppose it's not trivial to add support for another timeout parameter since C++ doesnt directly support this. Using something like detach is also a little dangerous.

Anyway using thread is dangerous, if we can't prevent user doing this I think at least we can find a way to detect situation like waiting for thread finish and give an warning.

[KoBeWi]

This is not really a bug. Tool scripts can break the editor in many ways. E.g. you can attach this to scene root:

@tool
extends Node
func _ready():
	queue_free()

and you'll get a startup crash. You need to be extra careful when using tool scripts.

[A-Totally-Normal-Name]

Tool scripts can break the editor in many ways... You need to be extra careful when using tool scripts.

That makes sense. The documentation gives good warnings for being careful with tool scripts in general as well.

I guess it's just not too obvious why it's crashing that's the problem. In @KoBeWi 's example its more intuitive to think that each time the scene loads in the editor, the scene tab should close, not the editor. Hence, it feels like a bug. In this issues example, it's not clear why the editor freezes up each time. Hence, it feels like a bug.

If it's not really feasible to add clarity to these crashes/freezes, and instead, it's sufficient to note a general caution when using tool scripts in the documentation, then this issue should probably just be closed.

[aXu-AP]

Altough freezing/crashing the editor is inevitable when user can run scripts within the editor, there could be some tools to work around problems like a bad tool script. Maybe ability to start the editor in a "safe mode", which doesn't run tool scripts? Possibly if 2 crashes have been detected in a project the project manager could suggest using safe mode.

[KoBeWi]

See godotengine/godot-proposals#2628

[MEEP202019]

i had this issue too, so i went into the game files and found the gd script. i opened it up in text editor and removed the @tool, and opened it. now it works.