godot: Project or editor crashes randomly from xcb XInitThreads
Godot version
v4.1.dev.custom_build [0291fcd7b]
System information
Linux Manjaro, kernel 6.1.19, X11
Issue description
The editor or the running project sometimes crashes with the following error:
[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot.linuxbsd.editor.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Crashes are more common while a project is running, but the editor also crashed because of this a couple of times over the past week or so.
I am not using any thread-related functions in my project, physics/rendering are not threaded, the project I’m working on as this happens is a simple GUI-based game.
Steps to reproduce
This seems to happen fairly randomly.
Minimal reproduction project
N/A
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 24
- Comments: 37 (11 by maintainers)
(FWIW, this isn’t RedHat-specific: I just got it with Debian, using libx11 1.8.7-1. FWIW I’m running Wayland.)
The code in
xcb_io.clooks like some hairy thing that’s trying hard to be thread-safe. But if it’s not successful, then this is the sort of error one might expect to see. And certainly different compilation options could affect how aggressively stuff gets reordered, which could affect thread safety. So I thought, why doesn’t Godot just put a mutex around the call? And then I looked, and it already had – in most cases.But consider the following rule (from
xcb_io.c):So we would expect the call to
XQueryTree(which, inside libX11, calls_XReply, which seems to be “reply-reading”) to also lock the same mutex – but it doesn’t.So it seems possible that there’s a race there.
XGetWindowPropertyis another possible culprit (the ones inscreen_get_usable_rectonly) . And XGetInputFocus. I haven’t fully audited to see if there are other cases than these three.I have only read the code, so this could be totally bogus. But it seems plausible.
Just another confirmation: After having crashes every 10 minutes, i’m using godot editor now for almost 4 hours without any issues after compiling libx11 by myself.
Please report the issue to https://gitlab.freedesktop.org/xorg/lib/libx11, it should not regress and break existing applications.
Even if we could find a workaround in Godot to not trigger whatever makes libx11 fail, all existing Godot releases and published games would still be broken. So libx11 needs to stop breaking Godot every other patch release.
Forgive my ignorance here, but given
libx11’s instability as of recently, would it make sense to vendor and statically link a properly patched version oflibx11in godot? Basically, if upstream cannot fix this (and/or keep it from regressing), can Godot take matters into its own hands? It won’t fix existing released games, but it might fix new ones, and provide an easy way for devs to re-release a game with the fix. Just my 2c, not sure if this makes sense.Reported: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/199 I hope we can get a fix before Fedora 40.
Manjaro kernel version: 6.1.22-1 As for GPUs: AMD RX 6800 XT but also Intel UHD Graphics 770 (CPU i7-12700) I have my screens connected to integrated graphics as I’m doing some GPU passthrough, this setup used to cause issues during the beta whenever I opened a new window or a submenu. Happened like 4 times mostly randomly when the editor was idling.
Managed to reproduce it when connected to gdb, adding backtrace as the attachment gdb.txt
Forgot to mention Godot version: custom build based on 4.0.2 stable
Single window mode also helps alot.
It seems that the problem no longer occurs in version 1.8.5 (Arch Linux official extra repository).
UPD. The problem appears again on libX11 1.8.7
Oh right, I forgot about GPU-related info. I have an AMD 7900 XT, running on the open-source amdgpu drivers with Mesa 22.3.5 (amdgpu version is “kernel”). The desktop is Plasma 5.26.5.