-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when Thread Model is set to Multi-Threaded #61650
Comments
Can you post a minimal project? I think I have this patched in my fork, but I need to find the exact patch branch. |
Tried the Rendering/Driver multi-threaded mode today in my project on 4.0.beta10 and it didn't crash on launch as described above, trying the minimal crash project about also doesn't crash for me. However, in the case of my project it did crash quite quickly playing the game (possibly related to an explosion effect with light and 3d particles) with no errors or warnings. This does not happen using the Single-Safe thread mode. So there still seem to be some stability issues with the Multi-threaded driver mode, even if some have been fixed since this bug report. |
Still crashes for me when activating a 3d particle effect on macOS 13, Godot 4.0beta12 if I switch to the Multi-Threaded mode instead of Single-Thread safe. So I think there's at least some issue that still there. |
I can't reproduce this on 4.0.beta 4c5e09f (Linux, NVIDIA 525.60.11). @lostminds Are you using CPUParticles or GPUParticles? #71359 reports the same issue when using CPUParticles. Also, what GPU model does your Mac have? |
They are CPUParticles3D spawning 50 sphere mesh particles. My GPU is a Radeon Pro 560 4 GB. |
Can confirm similar experience on macOS 12.6.3 with an RX580, at least with an existing project. Instantiating a CPUParticles3D in a scene causes a crash on launch. I can edit and preview particles no problem but they crash in the editor. I can also confirm this is not default behavior, as creating a new project, instantiating a CPUParticles3D node and then running the project does not cause a crash; I have not, however, investigated further. No error message in Godot; macOS provides a crash report which I can provide, if useful. I can also confirm that switching to Single Threaded, both safe and unsafe, prevents crashes. |
can confirm on 4.0stable |
I can't reproduce the issue myself on Linux with 4.0.stable with the provided reproduction project. Can people reproducing the issue locally reproduce it with the project in the OP? If not, can you provide a MRP which triggers the crash reliably? |
I can confirm too. I noticed Godot spamming these errors before crashing.
|
It seems that using animated textures + multithreading causes a crash. |
Windows 10, GPU with no Vulkan support. Crashes instantly on any scene I try, including those without particles or animated textures. Of course my OpenGL drivers are a bit old right now with official support ending time ago, but I want to see if it crashes instantly for other people in OpenGL mode too. It worked fine in Godot 3.5. |
I was frustrated I can't repro the GPU errors, so this one out, randomly, which grabbed my attention (I'm on latest master 262d1ea). The problem is that it ends up in an infinite recursion:
multimesh_set_buffer ends up calling flush_if_pending, which ends up calling multimesh_set_buffer (and tries to flush again). The value of UpdateSo it appears that _update_render_thread calls However despite being a virtual function, it doesn't seem to be overriden by anything except this:
Which is a macro that generates the following body: virtual void multimesh_set_buffer( RID p1, const Vector<float> &p2 )
{
RenderingServerDefault::redraw_request();
if (Thread::get_caller_id() != server_thread) {
command_queue.push(server_name, &ServerName::multimesh_set_buffer, p1, p2);
} else {
command_queue.flush_if_pending(); // ---> we are here
server_name->multimesh_set_buffer(p1, p2);
}
} |
IMO the problem is how the command queue is pushing the draw function and then using a sync command. This is very dangerous because it can create bizarre loops like the one described above. #77004 should theoretically solve this, but it will probably not be merged until there is a decision on what to do with OpenGL. |
Still crashes in current 4.2.1 stable with MT rendering. Crashes here: godot/core/templates/command_queue_mt.h Line 373 in 6128206
So as reduz pointed out - the problem is that from whitin |
Can't reproduce with 4.3dev6, but can with 4.3dev5, seems like fixed by #90268 |
Thanks for testing! |
Godot version
Godot Engine v4.0.alpha9.official.fc18891db
System information
5.15.0-33-generic #34-Ubuntu SMP Wed May 18 13:34:26 UTC 2022 x86_64 5700XT
Issue description
Projects run with Godot 4.0 alpha 9 instantly crash when Rendering>Driver>Threads>Thread Model is set to Multi-Threaded. The same project ran fine in alpha 8. Below is the output log.
Steps to reproduce
Set Thread Model to Multi-Threaded and run a project. Affects existing project, as well as new projects with no other changes made.
Minimal reproduction project
minimal_crash.zip
The text was updated successfully, but these errors were encountered: