Engine and/or entire computer crashes when resizing the game window and rendering/driver/threads/thread_model = Multi-Threaded

[nathanfranke]

Godot version

v4.0.alpha.custom_build [61f045245]

System information

Arch Linux x86_64, Kernel 5.15.61-1-lts, AMD RX 6800 XT, Mesa 22.1.6, Plasma 5.25.4, KWin+X11

Issue description

Similar to #58606

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (61f045245fbdf260245555bdf5be46f720daee01)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x38a40) [0x7f4c9c4f8a40] (??:0)
[2] /usr/lib/amdvlkpro64.so(+0xfd045c) [0x7f4c81e6a45c] (??:0)
[3] /usr/lib/amdvlkpro64.so(+0x11ee779) [0x7f4c82088779] (??:0)
[4] /usr/lib/amdvlkpro64.so(+0x12860b3) [0x7f4c821200b3] (??:0)
[5] VulkanContext::swap_buffers() (??:0)
[6] RenderingDeviceVulkan::swap_buffers() (??:0)
[7] RendererCompositorRD::end_frame(bool) (??:0)
[8] RenderingServerDefault::_draw(bool, double) (??:0)
[9] RenderingServerDefault::_thread_draw(bool, double) (??:0)
[10] CommandQueueMT::Command2<RenderingServerDefault, void (RenderingServerDefault::*)(bool, double), bool, double>::call() (??:0)
[11] CommandQueueMT::_flush() (??:0)
[12] CommandQueueMT::wait_and_flush() (??:0)
[13] RenderingServerDefault::_thread_loop() (??:0)
[14] RenderingServerDefault::_thread_callback(void*) (??:0)
[15] Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*) (??:0)
[16] void std::__invoke_impl<void, void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*>(std::__invoke_other, void (*&&)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*&&, Thread::Settings&&, void (*&&)(void*), void*&&) (??:0)
[17] std::__invoke_result<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*>::type std::__invoke<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*>(void (*&&)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*&&, Thread::Settings&&, void (*&&)(void*), void*&&) (??:0)
[18] void std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::_M_invoke<0ul, 1ul, 2ul, 3ul, 4ul>(std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul>) (??:0)
[19] std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::operator()() (??:0)
[20] std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> > >::_M_run() (??:0)
[21] /usr/lib/libstdc++.so.6(+0xd62f3) [0x7f4c9c8872f3] (??:0)
[22] /usr/lib/libc.so.6(+0x8678d) [0x7f4c9c54678d] (??:0)
[23] /usr/lib/libc.so.6(__clone+0x44) [0x7f4c9c5c78e4] (??:0)
-- END OF BACKTRACE --
================================================================

Steps to reproduce

1. Run MRP
2. Resize window

Minimal reproduction project

empty.zip

[jtnicholl]

I'm on Fedora 36, Radeon R9 390X with the amdgpu driver, also using Plasma. For me, resizing the window freezes the application on multi-threaded on X11. On Wayland it does crash, but with no stacktrace, it just prints double free or corruption (fasttop). Editor doesn't crash on X11 or Wayland.

[Calinou]

I can confirm this on 4.0.alpha ff04cb827 (Fedora 36, KDE Plasma + KWin on X11, NVIDIA 515.65.01).

Crash does not always happen when resizing, but dragging the resize handle slowly is a sure way to make it happen. X11 will appear to freeze for ~10 seconds when the engine crashes.

The default backtrace isn't very informative:

Godot Engine v4.0.alpha.custom_build.ff04cb827 - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080
 

================================================================
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.0.alpha.custom_build (ff04cb8279080e5fae6856d5204abfd686727780)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] /lib64/libc.so.6(+0x3ea70) [0x7fbe35a3ea70] (??:0)
[2] PopupMenu::_get(StringName const&, Variant&) const (/home/hugo/Documents/Git/godotengine/godot/scene/gui/popup_menu.cpp:1833)
[3] [0xc7d5f70] (??:0)
-- END OF BACKTRACE --
================================================================
[1]    21475 IOT instruction (core dumped)  bin/godot.linuxbsd.tools.64.llvm --path ~/Downloads/empty/

gdb gives a more complete backtrace:

(gdb) bt
#0  0x00007fffdd6be1cc in ?? () from /lib64/libnvidia-glcore.so.515.65.01
#1  0x00007fffdd69f344 in ?? () from /lib64/libnvidia-glcore.so.515.65.01
#2  0x00007fffdd5e5a96 in ?? () from /lib64/libnvidia-glcore.so.515.65.01
#3  0x00007fffdd5e5ba1 in ?? () from /lib64/libnvidia-glcore.so.515.65.01
#4  0x00007fffdd5e5d31 in ?? () from /lib64/libnvidia-glcore.so.515.65.01
#5  0x00007fffdf2a4a9b in ?? () from /lib64/libGLX_nvidia.so.0
#6  0x0000000005a8a438 in VulkanContext::_clean_up_swap_chain (this=0xa9902f0, 
    window=0xaba9548) at drivers/vulkan/vulkan_context.cpp:1538
#7  0x0000000005a888ad in VulkanContext::_update_swap_chain (this=0xa9902f0, window=0xaba9548)
    at drivers/vulkan/vulkan_context.cpp:1560
#8  0x0000000005a8aced in VulkanContext::prepare_buffers (this=0xa9902f0)
    at drivers/vulkan/vulkan_context.cpp:2056
#9  0x0000000005a17171 in RenderingDeviceVulkan::prepare_screen_for_drawing (this=0xad7d4f0)
    at drivers/vulkan/rendering_device_vulkan.cpp:9151
#10 0x0000000008a6238d in RendererCompositorRD::prepare_for_blitting_render_targets (
    this=0xa8f0830) at servers/rendering/renderer_rd/renderer_compositor_rd.cpp:37
#11 0x00000000088c2d10 in RendererViewport::draw_viewports (this=0xb25bc50)
    at servers/rendering/renderer_viewport.cpp:740
#12 0x0000000008939713 in RenderingServerDefault::_draw (this=0xb228e10, p_swap_buffers=true, 
    frame_step=0.0013591249999259595) at servers/rendering/rendering_server_default.cpp:91
#13 0x000000000893b07f in RenderingServerDefault::_thread_draw (this=0xb228e10, 
    p_swap_buffers=true, frame_step=0.0013591249999259595)
    at servers/rendering/rendering_server_default.cpp:336
#14 0x000000000898bff9 in CommandQueueMT::Command2<RenderingServerDefault, void (RenderingServerDefault::*)(bool, double), bool, double>::call (this=0xd9dfde8)
    at ./core/templates/command_queue_mt.h:322
#15 0x000000000848833c in CommandQueueMT::_flush (this=0xb229050)
    at ./core/templates/command_queue_mt.h:373
#16 0x0000000008481ee0 in CommandQueueMT::wait_and_flush (this=0xb229050)
    at ./core/templates/command_queue_mt.h:414
#17 0x000000000893b13d in RenderingServerDefault::_thread_loop (this=0xb228e10)
    at servers/rendering/rendering_server_default.cpp:358
#18 0x000000000893ab0d in RenderingServerDefault::_thread_callback (_instance=0xb228e10)
    at servers/rendering/rendering_server_default.cpp:345
#19 0x0000000009018f8f in Thread::callback (p_self=0xb2293e0, p_settings=..., 
    p_callback=0x893aaf0 <RenderingServerDefault::_thread_callback(void*)>, 
    p_userdata=0xb228e10) at core/os/thread.cpp:75
#20 0x0000000009019e3a in std::__invoke_impl<void, void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> (
    __f=@0xd04ec78: 0x9018f10 <Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*)>, __args=@0xd04ec58: 0xb228e10, __args=@0xd04ec58: 0xb228e10, 
    __args=@0xd04ec58: 0xb228e10, __args=@0xd04ec58: 0xb228e10)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/invoke.h:61
#21 0x0000000009019cb1 in std::__invoke<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> (
    __fn=@0xd04ec78: 0x9018f10 <Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*)>, __args=@0xd04ec58: 0xb228e10, __args=@0xd04ec58: 0xb228e10, 
    __args=@0xd04ec58: 0xb228e10, __args=@0xd04ec58: 0xb228e10)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/invoke.h:96
#22 0x0000000009019c2d in std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::_M_invoke<0ul, 1ul, 2ul, 3ul, 4ul> (this=0xd04ec58)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_thread.h:252
#23 0x0000000009019b95 in std::thread::_Invoker<std::tuple<void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >::operator() (this=0xd04ec58)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_thread.h:259
#24 0x0000000009019809 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(Th--Type <RET> for more, q to quit, c to continue without paging--
read*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> > >::_M_run (this=0xd04ec50)
    at /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/std_thread.h:210
#25 0x0000000009b31403 in execute_native_thread_routine ()
#26 0x00007ffff7a8ce2d in start_thread () from /lib64/libc.so.6
#27 0x00007ffff7b121b0 in clone3 () from /lib64/libc.so.6

[DomiStyle]

Same/similar issue still in Godot v4.0.beta2.mono.official (f8745f2)
Although only Godot freezes/crashes. Both on Wayland and X11 the compositor is fine.

Godot Engine v4.0.beta2.mono.official.f8745f2f7 - https://godotengine.org
[obs-vkcapture] Init Vulkan 1.2.0
Vulkan API 1.2.0 - Using Vulkan Device #0: AMD - AMD Radeon RX 6900 XT (RADV NAVI21)
[obs-vkcapture] Injecting VK_KHR_bind_memory2 extension
[obs-vkcapture] Injecting VK_KHR_get_memory_requirements2 extension
[obs-vkcapture] Injecting VK_KHR_external_memory_fd extension
[obs-vkcapture] Injecting VK_EXT_image_drm_format_modifier extension
libdbus-1.so: cannot open shared object file: No such file or directory
libdbus-1.so: cannot open shared object file: No such file or directory
 
double free or corruption (fasttop)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta2.mono.official (f8745f2f71c79972df66f17a3da75f6e328bc55d)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /home/domi/Downloads/data_GodotCrashWindowDrag/libcoreclr.so(+0x4dcdc1) [0x7fe3f35a4dc1] (??:0)
[2] /lib64/libc.so.6(+0x3ea70) [0x7fe454f6fa70] (??:0)
[3] /home/domi/Downloads/data_GodotCrashWindowDrag/libcoreclr.so(+0x4c59ac) [0x7fe3f358d9ac] (??:0)
[4] /home/domi/Downloads/data_GodotCrashWindowDrag/libcoreclr.so(+0x4dca6d) [0x7fe3f35a4a6d] (??:0)
[5] /lib64/libc.so.6(+0x3ea70) [0x7fe454f6fa70] (??:0)
[6] /lib64/libc.so.6(+0x8ec4c) [0x7fe454fbfc4c] (??:0)
[7] /lib64/libc.so.6(raise+0x16) [0x7fe454f6f9c6] (??:0)
[8] /lib64/libc.so.6(abort+0xcf) [0x7fe454f597f4] (??:0)
[9] /lib64/libc.so.6(+0x82d9e) [0x7fe454fb3d9e] (??:0)
[10] /lib64/libc.so.6(+0x9895c) [0x7fe454fc995c] (??:0)
[11] /lib64/libc.so.6(+0x9a722) [0x7fe454fcb722] (??:0)
[12] /lib64/libc.so.6(free+0x73) [0x7fe454fce103] (??:0)
[13] /usr/lib64/libvulkan_radeon.so(+0x144c6c) [0x7fe436c92c6c] (??:0)
[14] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x348db6b] (??:0)
[15] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x13cc373] (??:0)
[16] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x13cd2c4] (??:0)
[17] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x24e59ea] (??:0)
[18] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x24bc7b3] (??:0)
[19] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x24ac8a3] (??:0)
[20] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x2ad372a] (??:0)
[21] /home/domi/Downloads/GodotCrashWindowDrag.x86_64() [0x359f5b0] (??:0)
[22] /lib64/libc.so.6(+0x8ce2d) [0x7fe454fbde2d] (??:0)
[23] /lib64/libc.so.6(+0x1121b0) [0x7fe4550431b0] (??:0)
-- END OF BACKTRACE --
================================================================
./GodotCrashWindowDrag.sh: line 4: 77427 Aborted                 (core dumped) "$base_path/GodotCrashWindowDrag.x86_64" "$@"

[Calinou]

Removing platform:linuxbsd, as this was confirmed on Windows + AMD GPU in #75344.

[RobTheFiveNine]

I'm having the same issue in a project that isn't using the multi-threaded model; it's instead using Single-Safe. When I get the crash (both with my own project and the MRP from the OP), it completely crashes the desktop environment. Trying to kill the Godot process remotely over SSH results in it becoming a defunct process. The only way to bring the system back up is to do a hard reboot (even running reboot over SSH won't work).

I'm not sure if they are two different issues, as it seems if I switch to Single-Safe with OP's MRP, I can't make that crash, but Single-Safe in my own project results in the exact same crash when resizing the window (i.e. completely halting the DE).

System Info

• Godot version: v4.0.3.stable.official [5222a99f5]
• OS: Kubuntu 23.04, KDE Plasma 5.27.4, X11
• Kernel: 6.2.0-24-generic (64-bit)
• GPU: NVIDIA RTX 3070 Ti (using nvidia-driver-535)

[Dragoncraft89]

@RobTheFiveNine I can also reproduce this crash with Single-Safe. The back trace generated by gdb points to _clean_up_swap_chain as it is in the back trace shared above. The only difference being that it is called by window_set_vsync_mode instead of a prepare_buffers call.

Although I can only reproduce the crash when using Wayland. X11 seems to work fine

(Godot 4.1.1)

[psibean]

So this is interesting, using GodotSteam "macos-g413-s158-gs4421" Godot 4.1.3, I get the resize freeze when thread mode is set to Single Safe. If I set it to multi threaded - resizing works and the scenes run (from the editor) a lot nicer too. The editor continues to be responsive, only the game window hangs. If I use the stop option in the editor, it ends the game process successfully.

MBP Apple M1, 32GB ram, macOS Sonoma 14.1 (23B74)

[pkdawson]

I think there's been some work on the multi-threaded renderer recently, and I can now only reproduce this crash (on Windows/NVIDIA) when vsync is disabled.

Here's an automatically-resizing MRP which crashes within seconds on a current build (5675c76). It doesn't crash on macOS, haven't tested Linux.

mt_renderer_crash.zip