ResourceLoader.load_threaded_request() hangs for use_sub_threads = true with no error messages

[danny88881]

Godot version

v4.2.rc1.official [ad72de5]

System information

Godot v4.2.rc1 - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.3758) - 11th Gen Intel(R) Core(TM) i5-11400 @ 2.60GHz (12 Threads)

Issue description

ResourceLoader.load_threaded_request() hangs indefinitely for use_sub_threads = true with no error messages.
It happens when you have an instance of a resource in a scene and are trying to preload the resource in the script of the scene.

I think it could be deadlock and the threads are stuck busy waiting, but I'm just speculating as there is no error message and I haven't looked into the source code.

Happens in v4.1.2.stable.official [399c9dc] and v4.2.rc1.official [ad72de5]

might be similar to #71726

Steps to reproduce

1. Create a scene "S1" with script
2. Create a scene "S2" with script and preload "S1" within the script
3. Create an instance of "S1" within "S2"
4. Try to call "ResourceLoader.load_threaded_request()" on "S2" with "use_sub_threads = true"

Minimal reproduction project

ResourceLoaderTest.zip

[danny88881]

Not sure how common this issue is but I'm working around it by doing separate calls to "ResourceLoader.load_threaded_request()" for those specific instanced and preloaded scenes before loading the larger scene.

[akien-mga]

Could you test the build linked here?
#85039 (comment)

[danny88881]

Yeah, still stuck at 0% with no error messages.

[akien-mga]

Confirmed on Linux with latest master branch (ce3bac5).

When closing the MRP, it deadlocks. GDB gives this stacktrace:

(gdb) bt
#0  0x00007f8daa1b4785 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
#1  0x00007f8daa1b8fe3 in nanosleep () from /lib64/libc.so.6
#2  0x0000000006c05a05 in OS_Unix::delay_usec (this=0x7ffd528bfee0, p_usec=1000) at ./drivers/unix/os_unix.cpp:283
#3  0x0000000009a323ad in ResourceLoader::clear_thread_load_tasks () at ./core/io/resource_loader.cpp:1054
#4  0x000000000579a437 in Main::cleanup (p_force=false) at main/main.cpp:3765
#5  0x000000000570bc0a in main (argc=10, argv=0x7ffd528c04c8) at platform/linuxbsd/godot_linuxbsd.cpp:76

I confirm the issue is reproducible in 4.2-rc1, 4.1-stable and 4.0-stable, so it's not a recent regression.

[jsjtxietian]

Crawling some stucked stack trace, looks like they all wait for semaphore, likes the task is having some trouble proceed, it does look suspicious:

[Hilderin]

I think I have the same issue with a test project for another issue #58131:
https://drive.google.com/file/d/1tLpW8EjPWoQJak68OMZzhFvNNdf1FKfs/view?usp=sharing

I'm on Windows 11, Godot v4.3.dev.custom_build [4f55118f4]

The problem seems to be caused by a thread conflict between the resource loader and the toast because the project has some invalid .import for the pngs.

If a was able to figure out that the Editor tries to add a message for the invalid loader from a thread and another thread is trying to add the toast but is not in the main thread so it raisesanother error

After that the editor is completly frozen:

Adding a return in EditorToaster::popup_str fixes the problem.

[Hilderin]

Yes, I think I found the problem, but I'm not sure how to fix it.
The problem is caused because the ResourceLoader takes control of the MessageQueue but if an error occurs during the loading of resources, the message queue is beeing flushed and in this queue we got the error message from the loader, but after that, at each flush we receive the error telling us that we are not on the main thread on execute add_child from the EditorToaster.

I'm not sure if a tweak in the EditorToaster is the right move and removing the MessageQueue from the ResourceLoader is probably a really bad idea.

Just adding these lines at the beginning of EditorToaster::_popup_str fix the problem, the only inconvenient is that the error message from the loading of resource async will not be displayed in toasts, which in my opinion is not a big problem:

if (!Thread::is_main_thread()) {
	return;
}

This screenshot shows the problem clearly:

[akien-mga]

CC @groud @RandomShaper

[akien-mga]

As I wrote in #92426 (comment), @Hilderin's issue seems to be different from the OP's.

#92426 will fix that later report (EditorToaster deadlock), but not the OP's problem.