Freeze when a window or popup is open (Linux with i3) (workaround: Use --single-window)

[pouleyKetchoupp]

Godot version:
Master b0ca859

OS/device including version:
Ubuntu 20.04 / WM: i3

Issue description:
This issue is specific to i3 (tiling window manager).

In multi-windows mode, the whole editor freezes for a few seconds each time a new window is opened, or when the focus switches from the editor or back to the editor.

It doesn't seem to be related to a specific change in Godot but didn't happen before, so it might be due to an update in i3 or one of its dependencies.

More details here: #41456 (comment)

Steps to reproduce:
Can be reproduced easily by starting the editor with any project, using i3 window manager.

Minimal reproduction project:
n/a

[DavidNexuss]

Can confirm same thing happens with Arch Linux, I've test so far the following WMs and their last versions at the moment of writing this:

• bspwm 0.9.10-1
• gnome (gnome-desktop 1:3.36.5-1 the x11 version)
• kde plasma (plasma-desktop 5.19.4-1)

The whole editor freezes each time a popup or a window is created, the error seem more related to the latest versions of xorg packages as to me its seems more WM agnostic, at least on Arch Linux. I also tried to replicate the issue with dwm though in this one godot just crashed instead of freezing the editor.

I made the tests with a fresh build of godot in release_debug in the latest commit on the master branch 1ff139c and b0ca859

[Riteo]

If I reproduce this issue while editing a project, the editor freezes completely.

[Riteo]

After a lot of ideas, tests and weird behaviour, I found a workaround which is getting us closer and closer to the exact cause of the freezing.
Since this freeze never happened before, and could be replicated even on old builds, I tried to rollback all possibly related packages with godot.
I found out eventually that by downgrading NVIDIA's drivers from version 450.66 to 450.57 the freezing doesn't happen anymore.

Edit: I searched for the changelog of this new version, and the only change reported is:

Fixed triple buffering support of Vulkan X11 swapchains when applications are syncing to vblank.

I'll investigate further as soon as I can.

[nathanfranke]

This can be worked around by enabling Single Window Mode.

Since you can't really open editor settings with this bug, edit ~/.config/godot/editor_settings-4.tres and under [resource] add interface/editor/single_window_mode = true

[Calinou]

@nathanfranke To force single-window mode, you can also pass the --single-window command-line argument.

[Riteo]

I've never worked with Vulkan, 3D graphics nor a debugger before, so I'm sorry for any ignorance or mistakes on any informations related to them, expecially with terminology. Also, its 4:30 AM at the time of writing this, so there may be some grammatical issues too.

On my Arch Linux machine, with the currently latest NVidia drivers(version 450.66), running a build of 5abb53b this is what I found out in these last days:

It seems that Godot actually freezes along with the X11 server in two different ways internally, one way when the window is opened, and another when the focus is changed.

In the first way, Godot gets stuck on this line, which seems to wait for either &image_ownership_semaphores[frame_index] or &draw_complete_semaphores[frame_index] depending on the system configuration, which I believe are set for signaling here and here, respectively.
Here is a backtrace of this freeze:

0  0x00007f98230f0f80 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#1  0x00007f9823235830 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#2  0x00007f98232358f7 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#3  0x00007f98231dde01 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#4  0x00007f9823568a80 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#5  0x00007f982356c389 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#6  0x00007f9823560c1b in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#7  0x00007f98234d6c79 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#8  0x00007f9829f98c5e in ?? () from /usr/lib/libGLX_nvidia.so.0
#9  0x0000000002a5b80b in VulkanContext::swap_buffers (this=0x7ab9750) at drivers/vulkan/vulkan_context.cpp:1433
#10 0x0000000002a1c726 in RenderingDeviceVulkan::swap_buffers (this=0x7d80300) at drivers/vulkan/rendering_device_vulkan.cpp:6933
#11 0x00000000044b7d28 in RasterizerRD::end_frame (this=0x8376010, p_swap_buffers=true) at servers/rendering/rasterizer_rd/rasterizer_rd.cpp:95
#12 0x00000000043f47ed in RenderingServerRaster::draw (this=0x81cafd0, p_swap_buffers=true, frame_step=0.0083333337679505348)
    at servers/rendering/rendering_server_raster.cpp:116
#13 0x000000000442b610 in RenderingServerWrapMT::draw (this=0x8b5cc70, p_swap_buffers=true, frame_step=0.0083333337679505348)
    at servers/rendering/rendering_server_wrap_mt.cpp:91
#14 0x0000000001a1ff20 in Main::iteration () at main/main.cpp:2412
#15 0x00000000019e8d8a in OS_LinuxBSD::run (this=0x7fff155ec3d0) at platform/linuxbsd/os_linuxbsd.cpp:240
#16 0x00000000019e68e8 in main (argc=4, argv=0x7fff155ec8c8) at platform/linuxbsd/godot_linuxbsd.cpp:58

In the second way, Godot gets stuck on vkDeviceWaitIdle() on this line, while cleaning up the swap chain.
Here is a backtrace of this freeze:

#0  0x00007f982af9946f in poll () from /usr/lib/libc.so.6
#1  0x00007f98230f3cd4 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#2  0x00007f98234cd799 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#3  0x00007f98234ec3cd in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#4  0x00007f98234cc78d in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#5  0x00007f98234ce246 in ?? () from /usr/lib/libnvidia-glcore.so.450.66
#6  0x0000000002a6233c in vkDeviceWaitIdle (device=0x7d82460) at thirdparty/vulkan/loader/trampoline.c:887
#7  0x0000000002a5977e in VulkanContext::_clean_up_swap_chain (this=0x7ab9750, window=0x98b3598) at drivers/vulkan/vulkan_context.cpp:767
#8  0x0000000002a596f2 in VulkanContext::window_destroy (this=0x7ab9750, p_window_id=1) at drivers/vulkan/vulkan_context.cpp:758
#9  0x00000000019f09aa in DisplayServerX11::delete_sub_window (this=0x7a983b0, p_id=1) at platform/linuxbsd/display_server_x11.cpp:702
#10 0x00000000037e2171 in Window::_clear_window (this=0x9ac63f0) at scene/main/window.cpp:275
#11 0x00000000037e2f77 in Window::set_visible (this=0x9ac63f0, p_visible=false) at scene/main/window.cpp:377
#12 0x00000000037e2e3b in Window::hide (this=0x9ac63f0) at scene/main/window.cpp:353
#13 0x0000000001a76bfc in MethodBind0::call (this=0x8ce0340, p_object=0x9ac63f0, p_args=0x0, p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:59
#14 0x000000000479a6ea in Object::call (this=0x9ac63f0, p_method=..., p_args=0x0, p_argcount=0, r_error=...) at core/object.cpp:797
#15 0x000000000470abea in Callable::call (this=0x7f982a372020, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/callable.cpp:52
#16 0x00000000047915f5 in MessageQueue::_call_function (this=0x7a08660, p_callable=..., p_args=0x7f982a372038, p_argcount=0, p_show_error=false) at core/message_queue.cpp:258
#17 0x0000000004791932 in MessageQueue::flush (this=0x7a08660) at core/message_queue.cpp:304
#18 0x000000000378554f in SceneTree::iteration (this=0x7bb32e0, p_time=0.0166666675) at scene/main/scene_tree.cpp:414
#19 0x0000000001a1fc35 in Main::iteration () at main/main.cpp:2375
#20 0x00000000019e8d8a in OS_LinuxBSD::run (this=0x7fff155ec3d0) at platform/linuxbsd/os_linuxbsd.cpp:240
#21 0x00000000019e68e8 in main (argc=4, argv=0x7fff155ec8c8) at platform/linuxbsd/godot_linuxbsd.cpp:58

In both backtraces, right after these waiting functions, there are some unknown functions from a library of NVidia's drivers, which after updating to 450.66 gave these issues. Maybe something related to syncronization may have changed in them.

This should be the forum post reporting the issue fixed in the last version of the driver, I still haven't read it whole, but maybe there could be something useful.

I also read a bit the Vulkan specifications, and at first glance the affected source files seem to be following them. Since even older, previously working revisions of the source code would still freeze, I don't think that the issue resides in the code, could it be in the driver?

I did some research with my newly obtained function names and the closest reported issue I could find to this one was this reddit post which seems to have a similar problem to what I found with vkDeviceWaitIdle() that also has a machine running Arch Linux with NVidia drivers, even though it's from 2 months ago using an older beta driver which seems to have been publicly hidden for some reason, by looking up this forum post. That beta version seems to be related to a laptop syncing issue though, so what that reddit user may have experienced may not even be related to our issue at all.

I took 2 hours and an half to write this message because I kept adding new stuff. I could have continued researching more, but I really, really have to go to sleep. I hope that this information could be useful, and to have written something coherent.

[Riteo]

Can somebody without an NVidia card try to reproduce this issue on i3wm?

[pouleyKetchoupp]

I've confirmed this is due to an issue with nvidia drivers.

I don't reproduce the issue anymore when disabling my nvidia card and enabling my Intel GPU instead.

I can reproduce it with the default/recommended proprietary version on Ubuntu (440.100).
I can't confirm how it goes with more recent drivers, as drivers 450.66 don't work at all on my configuration (nothing is rendered in any app using 3d acceleration).

Possible workaround:
I was able to solve the issue by disabling PRIME synchronization on my nvidia card:
-Create file /etc/modprobe.d/nvidia-graphics-drivers.conf
-Add line options nvidia-drm modeset=0
-Run sudo update-initramfs -u
-Reboot

[akien-mga]

I think that there are two issues here:

• Freeze on Linux with i3wm with Nvidia drivers, which apparently happens with both Nvidia 440.100 and 450.66 according to Freeze when a window or popup is open (Linux with i3) (workaround: Use --single-window) #41574 (comment)
• Freeze on Linux on different window managers (at least GNOME Shell) with Nvidia drivers, which are a regression in 450.66 (440.x work fine), and possibly a regression between 450.57 and 450.66 as per Freeze when a window or popup is open (Linux with i3) (workaround: Use --single-window) #41574 (comment)). Some of the issues closed as duplicates of this one are in this scenario (Godot completely hangs when  #41863, DisplayServer::_create_window freeze IDE on nVidia driver 450 #42246), and @Faless confirmed it on IRC too.

Should a new issue be opened to track the Nvidia 450.66 regression which is not specific to tiling WMs?

And at this point we need to start talking with upstream as this regression is pretty bad.

[pouleyKetchoupp]

Agreed!

Concerning the 450.66 driver regression we have #41614, which was initially reported as an Arch issue but happened to be linked to the nvidia driver version.

[EzraT]

I can confirm this also happens on Cinnamon in Linux Mint 20 using Nvidia Driver 450.80.02.
Same thing for 455.38.

[nathanfranke]

@nathanfranke To force single-window mode, you can also pass the --single-window command-line argument.

@Calinou This sounds good in theory, but

[Calinou]

@nathanfranke See #41614 (comment).

[pouleyKetchoupp]

Can anyone still reproduce the consistent freezing with i3wm? (I'm not talking about #41614).

It happened consistently when changing windows focus before, but this issue seems to be fixed for me with drivers 465.31 on Arch Linux.

[Riteo]

@pouleyKetchoupp I'm pretty sure it was never related to i3, as implied by my original comment.

[pouleyKetchoupp]

@Riteo Are you sure you're not talking about #41614? There are two different issues that look similar.

1. The issue I was able to reproduce with i3 was a freeze for a few seconds when changing windows focus systematically. I was able to reproduce it with vkcube as well, and with Nvidia drivers version 440.

2. On the other hand, GUI unresponsive on Godot 4 (regression from the NVIDIA Linux 450.66 driver and later) #41614 is not specific to the window manager, and can be reproduced starting with Nvidia drivers 450.66. It freezes randomly when opening some sub-windows within godot.

Is that correct?

If nobody can reproduce 1. then this issue can be closed, while 2. still needs investigation because it seems to still happen for some users on the latest driver version.

[Riteo]

@pouleyKetchoupp oh I can replicate that but I always thought that for some reason #41614 and this were somehow the same thing (see my very long comment related to the other issue), my bad!

[Calinou]

This should be fixed in 4.0 since alpha1 at least, closing. I can't reproduce it here anymore at least.

If you can still reproduce this, please open a separate issue.