Help search randomly becomes empty

[KoBeWi]

Godot version

ecc86af

System information

Windows 10 x64

Issue description

Doesn't display anything whatever I type. Seems to happen randomly when I use editor for extended period of time (including just idling in background).

I've seen some similar issues, but they don't look the same. This one doesn't have clear cause and can only be fixed by restarting editor.

Steps to reproduce

1. No idea
2. Just use editor I guess

Minimal reproduction project

No response

[snailrhymer]

I've seen this in builds post alpha 12, but likewise can't find a cause. Could be related to #63334?

[KoBeWi]

I actually didn't see this in the most recent builds (~1 week) in a similar circumstances, so this might be fixed. I will wait a bit more to see if it doesn't happen again.

EDIT:
This comment is unfortunate given the date of this issue 🙃
I was probably using older build than stated in the OP.

[snailrhymer]

Yeah, on reflection I can't be sure when it was that I saw it.

When it did happen, it seemed relatively frequent and I haven't seen it for a while either, so +1 for possibly fixed.

[KoBeWi]

Ok it happened again. Still don't know why.

[TokisanGames]

Just ran into this in 5c6744a. Moving all around the engine, clicking on stuff, opening and closing scenes, nothing brings it back. Closing and reopening the engine fixed it for now.

[TokisanGames]

This has been happening constantly for me. It's likely caused because the new help system searches and lists my own classes and functions. However I'm still converting my project, so many classes are broken and the help system is not robust. The help system breaks itself and gets stuck in an infinite loop, slowing down the editor even if you close the help window.

On my system I can load my project, then access help fine. However when I open a scene and start to add a node, I get console errors about various broken scripts. I cancel the add. Then if I pull up help, it is blank, and I notice my editor is a little sluggish.

Here's what I found debugging.

The F1 Editor help search dialog opens here, but that just begins a background search process:

godot/editor/editor_help_search.cpp

Line 158 in dbd1524

void EditorHelpSearch::popup_dialog(const String &p_term) {

The work is done here:

godot/editor/editor_help_search.cpp

Line 279 in dbd1524

bool EditorHelpSearch::Runner::_slice() {

After having getting a blank help, and closing the window, I found that _slice() is still being called. It keeps going into the _phase_match_classes() match, meaning phase_done is always false and the process never stops.

godot/editor/editor_help_search.cpp

Line 325 in dbd1524

bool EditorHelpSearch::Runner::_phase_match_classes() {

Descending into that function I find this:

bool EditorHelpSearch::Runner::_phase_match_classes() {
	DocData::ClassDoc &class_doc = iterator_doc->value;
	if (class_doc.name.is_empty()) {  
		return false;    
	}
        ...

class_doc is a ClassDoc but it is empty, so the function returns false, preventing _slide() from ever finishing, even when the window is closed or it has run into errors from broken scripts it failed to enumerate.

It was probably caused by the combination of the two most recent edits to this section: #54406 @fire
and #60999

[KoBeWi]

Doesn't seem to happen anymore after #65624
I might reopen if it happens again (unlikely).

[snailrhymer]

Finally managed to get this reproducible in alpha12, with a particular sequence of class inheritances:

2022-09-16.00-19-42.mp4

Class 1:
extends Node
Class 2:
extends res://Class1.gd
class_name Class2
Class 3:
extends Class3

and as shown in the video, there's some dependence on nodes in the current (?) scene.

In some other build pre-#65624, I've also seen this sequence cause a slightly different behaviour - where the help search would not be empty but an infinite loop would still be running in the background, slowing down the editor and making my fans go wild until the editor was closed. I think this was caused by the Runner getting to the next match phase before hitting one of the fail conditions.

---

In beta1, #65624 seems to have reverted the behaviour to the crashes that #54406 was intended to prevent:

2022-09-16.00-01-40.mp4