Fix crash on queue free scene node in editor

[xuhuisheng]

• Fixes Editor hard crashes upon loading a scene with a node using queue free #112171

Issue Description

When we try to delete scene root node using queue_free in editor, we will meet a crash. The marked node will be freed defer. But the editor still want to redraw relevant plugins for scene root node, then crashed.

It is an abnormal behavior to delete a node in editor in @tool annotated gdscript. If we delete a child node, we will see the child node disappeared from left EditorTreeDock menu. If we delete the root node, the scene cannot display normally.

# First, enable gdscript running in editor
@tool
extends Node2D

func _ready() -> void:
	# Second, queue free scene root node 
	queue_free()

MRP

112171-1.zip

Solution

Prohibit queue_clear to delete scene root node in editor.

queue-free.webm

[Ivorforce]

We discussed this fix in the core meeting.
We agree that the approach you take (rejecting the object deletion in the editor only) is appropriate.

However, there are two changes I think are needed:

• Check for whether it's actually the editor via Engine::get_singleton()->is_editor_hint(). Otherwise, the runtime using the editor binary will also reject the deletion, causing a discrepancy in DEBUG vs RELEASE.
• Move this check to node.cpp in the NOTIFICATION_PREDELETE handler, right after the is_main_thread check. This will prevent the same kind of bug when using .free() and memdelete. You can reject deletion here using cancel_free() (and return).

[xuhuisheng]

@Ivorforce

Modified as suggestions.
Test passed locally.

[Ivorforce]

Looks good to me, thanks for adjusting.

I tested that this new version still fixes the issue.

[kleonc]

Fixes both #66196 and #68544 which are both reported for 3.x. After migrating the MRPs to 4.x they no longer crash with this PR. Not sure if we want to keep the issues open for 3.x or what.

Fixes #81320 (makes it spam errors instead of crashing as it tries to free the scene root in _process()).

[Ivorforce]

cc @lawnjelly ^

[lawnjelly]

Not sure if we want to keep the issues open for 3.x or what.

Generally the method I'm aiming for is this:

• If a bug is open against 3.x and it gets fixed in 4.x but not in 3.x, the bug is still open in 3.x (sadly fixing it in 4.x doesn't magically fix it in 3.x! 😁 )
• If a bug report in 3.x has been "kidnapped" to 4.x, and is fixed in 4.x but not in 3.x, we should aim to change the milestone back to 3.x

In this case though, this fix looks fairly easy to backport, if we've decided this is the best way of addressing it. 👍

[Repiteo]

Thanks!