Project or editor crashes randomly from xcb XInitThreads

[Cykyrios]

Godot version

v4.1.dev.custom_build [0291fcd]

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

[Calinou]

I haven't been able to reproduce this so far on Fedora 37 KDE (GeForce RTX 4090 with NVIDIA 525.89.02).

What graphics card model, driver version and desktop environment are you using?

Edit: As of November 2023, I've started to be able to reproduce this issue on the same setup as mentioned above (with Fedora 38 and then 39).

[Cykyrios]

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.

[geowarin]

Saw this happening (only once) on a totally different config:
RTX 2080Ti
archlinux
i3wm

[cg9999]

I have this too, again. Seems very reminiscent of #69352
Happens quite frequently here.
The message varies a bit, last one I got is:

[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot: xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

Godot: v4.0.1.stable.arch_linux
libx11: 1.8.4-1
arch linux 64 bit, kernel 6.2.8-zen1
On a laptop with Intel HD Graphics 620

[DrRevert]

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

[Eraph]

Seeing the same thing on Manjaro here, I have integrated Intel graphics (Intel i7-1165G7). Gnome on Wayland. Common factor seems to be Arch based distros?

Full backtrace:

handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.2.stable.mono.official (7a0977ce2c558fe6219f0a14f8bd4d05aea8f019)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.3/libcoreclr.so(+0x4a90a4) [0x7f5d0658b0a4] (??:0)
[2] /usr/lib/libc.so.6(+0x38f50) [0x7f5d35225f50] (??:0)
[3] /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.3/libcoreclr.so(+0x49296b) [0x7f5d0657496b] (??:0)
[4] /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.3/libcoreclr.so(+0x4a8d18) [0x7f5d0658ad18] (??:0)
[5] /usr/lib/libc.so.6(+0x38f50) [0x7f5d35225f50] (??:0)
[6] /usr/lib/libc.so.6(+0x878ec) [0x7f5d352748ec] (??:0)
[7] /usr/lib/libc.so.6(gsignal+0x18) [0x7f5d35225ea8] (??:0)
[8] /usr/lib/libc.so.6(abort+0xd7) [0x7f5d3520f53d] (??:0)
[9] /usr/lib/libc.so.6(+0x2245c) [0x7f5d3520f45c] (??:0)
[10] /usr/lib/libc.so.6(+0x319f6) [0x7f5d3521e9f6] (??:0)
[11] /usr/lib/libX11.so.6(+0x3eb8f) [0x7f5d2d888b8f] (??:0)
[12] /usr/lib/libX11.so.6(+0x41995) [0x7f5d2d88b995] (??:0)
[13] /usr/lib/libX11.so.6(_XEventsQueued+0x62) [0x7f5d2d88e642] (??:0)
[14] /usr/lib/libX11.so.6(XFlush+0x1f) [0x7f5d2d86bc1f] (??:0)
[15] /opt/godot-mono-bin/godot/Godot_v4.0.2-stable_mono_linux.x86_64() [0x4d62051] (??:0)
[16] /opt/godot-mono-bin/godot/Godot_v4.0.2-stable_mono_linux.x86_64() [0xe792eb] (??:0)
[17] /opt/godot-mono-bin/godot/Godot_v4.0.2-stable_mono_linux.x86_64() [0x4217f35] (??:0)
[18] /opt/godot-mono-bin/godot/Godot_v4.0.2-stable_mono_linux.x86_64() [0x4e38160] (??:0)
[19] /usr/lib/libc.so.6(+0x85bb5) [0x7f5d35272bb5] (??:0)
[20] /usr/lib/libc.so.6(+0x107d90) [0x7f5d352f4d90] (??:0)
-- END OF BACKTRACE --

[vypxl]

Having the same issue, Manjaro with Hyprland / Wayland here. Also Godot 4.0.1 stable, libx11 v1.8.4-1, intel integrated graphics.

[ilmagico]

Can confirm on Manjaro with kernel 6.1.23, X11 (no wayland) with libx11 1.8.4-1 as well, intel integrated, godot 4.1 compiled from source (from a fork not far from master, but judging from this report the issue is in godot, I could confirm if necessary), backtrace is exactly the same as @Eraph above.

Also, I noticed this is with .NET 7.0.3, while if I download the official stable godot mono from godotengine.org (not from Manjaro's pacman) it never crashes this way, and it's on .NET6, not sure if it matters.

Any other info I could provide to help debug this?

[ju5tevg3niy]

Same issue.

godot:  4.0.2.stable.official.7a0977ce2
render: Vulkan API 1.3.230 - Forward Mobile - Using Vulkan Device #0: Intel - Intel(R) HD Graphics 620 (KBL GT2)
os:     Gentoo
kernel: 6.1.22
de:     Xfce 4.18 / X11
libX11: 1.8.4-r1

[comminux]

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

[jivvy]

Just had this happen

swaywm
Arch Linux
AMD 6700XT
Godot v4.2.dev.custom_build [f8dbed4]
libx11 1.8.6-1

[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot.linuxbsd.editor.x86_64: xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

[krendil]

I'm getting the same error, with a recent libX11 and non-Arch Linux

Godot Engine v4.1.1.stable.custom_build
OpenGL API 4.6 (Core Profile) Mesa 23.1.3 - Compatibility - Using Device: AMD - AMD Radeon RX 6600 (navi23, LLVM 15.0.7, DRM 3.52, 6.3.13_1)

Void Linux
XFCE4 / xfwm 4.18.0_1
libX11 1.8.6_1
libxcb 1.16_1

[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot: xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

[Leshy-YA]

Confirmed on Fedora running KDE with Mesa Intel® Xe Graphics.
It would seem there's a regression in libX11 1.8.7, probably related to https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/170
Downgrading libX11 to 1.8.4 removes the issue.

[ZwieBit]

Can also confirm that a downgrade to libX11 1.8.4 fixed the issue. I already thought that godot is somewhat unstable but now even 4.2 beta1 works like a charm :-)

[Pshy0]

I am having similar crashes involving xcb_in.c. They are unpredictable, sometimes crashing the project, sometimes crashing the editor, sometime just displaying in logs without a crash.

Ubuntu 23.04
Godot 4.2.dev4.official.549fcce5f
libx11 1.8.4-2ubuntu0.3
libxcb 1.15-1

The error messages are as follow:

[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot: ../../src/xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

or

[xcb] Unknown sequence number while awaiting reply
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot: ../../src/xcb_io.c:374: poll_for_response: Assertion `!xcb_xlib_threads_sequence_lost' failed.

or

godot: ../../src/xcb_in.c:757: xcb_request_check: Assertion `!reply' failed.

It also sometimes crashes without an error message.

[vvvvvvitor]

Keeps happening here all the time, it makes editor basically unusable due to how often it happens. It's really frustrating to the point of me not wanting to work on my project anymore.

[xcb] Unknown sequence number while awaiting reply [xcb] You called XInitThreads, this is not your fault [xcb] Aborting, sorry about that. 4.1.3.x86_64: xcb_io.c:374: poll_for_response: Assertion !xcb_xlib_threads_sequence_lost' failed.
`

[ygingras]

On Ubuntu 23.04, all of Godot 4.1.1, 4.1.2, 4.1.3 crash about three times per hour. If I downgrade xserver-xorg-core from 2:21.1.7-1ubuntu3.1 to 2:21.1.7-1ubuntu3, then the crashes happen only once every few days.

Edit: fixed the version numbers

[vvvvvvitor]

On Ubuntu 23.04, all of Godot 4.1.1, 4.1.2, 4.1.3 crash about three times per hour. If I downgrade xserver-xorg-core to 2:21.1.7-1ubuntu3.1, then the crashes happen only once every few days.

Single window mode also helps alot.

[Leshy-YA]

This is becoming more critical.

Fedora 39 does not have an option to downgrade libX11 from libX11-1.8.7-1. That means Godot in any form becomes unusable in Fedora 39 and other current distros.

[akien-mga]

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.

[Leshy-YA]

Please report the issue to https://gitlab.freedesktop.org/xorg/lib/libx11, it should not regress and break existing applications.

Reported: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/199 I hope we can get a fix before Fedora 40.

[ilmagico]

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 of libx11 in 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.

[Lamby777]

Yep, now I have a reason not to feel bad about catching myself subconsciously spamming CTRL+S.

Milestone shows 4.3, would the fix last or do you guys think an update gonna break it again soon after? Might just downgrade libx11 if it gets really annoying but I'm kinda too busy to troubleshoot stuff rn if doing so happens to break any of my other packages. ;-;

[granitrocky]

@Lamby777 Upgrading libx11 works, too. I compiled and installed the latest libx11 from master on fedora 39 by doing

https://gitlab.freedesktop.org/xorg/lib/libx11/-/tree/master

./autogen.sh
./configure --prefix=/usr
make
sudo make install

and then reboot and I haven't had a crash yet.

[QueenOfSquiggles]

Gonna share I'm experiencing this regularly on my Manjaro KDE machine.
System details here:

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.11
Kernel Version: 6.5.13-7-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 × AMD Athlon(tm) X4 880K Quad Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.

Currently working with Godot 4.2-Stable running it from the command line so I get more interesting details.

Error from terminal:

[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
Godot_v4.2-stable_linux.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
zsh: IOT instruction (core dumped)  $GODOT4_BIN -e .

[acolbert1986]

System info...

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.11
Kernel Version: 6.1.69-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 12 × 12th Gen Intel® Core™ i5-12500T
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 770
Manufacturer: Dell Inc.
Product Name: OptiPlex 3000

Error in terminal...

Godot Engine v4.2.1.stable.arch_linux - https://godotengine.org

[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot: xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
[1]    2223 IOT instruction (core dumped)  godot --editor --verbose --single-window

[akien-mga]

@Lamby777 Upgrading libx11 works, too. I compiled and installed the latest libx11 from master on fedora 39 by doing

https://gitlab.freedesktop.org/xorg/lib/libx11/-/tree/master

./autogen.sh ./configure --prefix=/usr make sudo make install

and then reboot and I haven't had a crash yet.

That's weird, as the latest master commit of libx11 is the 1.8.7 release which is shipped by Fedora.

So there's a difference between the Fedora package for libX11-1.8.7-1.fc39 and the one you compiled locally. It can be a different set of install dependencies so that your local builds adds or removes a feature, or this patch that Fedora is chugging along https://src.fedoraproject.org/rpms/libX11/blob/rawhide/f/dont-forward-keycode-0.patch, or any of the other custom tweaks in their .spec file, though I don't see much that sounds relevant: https://src.fedoraproject.org/rpms/libX11/blob/rawhide/f/libX11.spec

Either way, I suggest also opening a Fedora bug report, as the upstream libX11 report isn't getting any traction and we now have evidence that a self-compiled libx11 performs differently.

[Leshy-YA]

Either way, I suggest also opening a Fedora bug report, as the upstream libX11 report isn't getting any traction and we now have evidence that a self-compiled libx11 performs differently.

Done: https://bugzilla.redhat.com/show_bug.cgi?id=2256495

[ionenwks]

Possible CFLAGS are involved and some UB is causing this? aka when you built libX11 manually from master I'd assume you didn't use the same (possibly just a plain -O2). I don't really keep up with fedora, but believe they use LTO nowadays for one? (Edit: as for autoconf options, they don't pass anything notable I can see, the keycode patch sounds harmless too -- not that I looked too closely)

Haven't run into crashes with 1.8.7 myself on Gentoo, albeit I may not use it enough to run into these (I just test godot a bit for packaging, haven't got bug reports either way).

[akien-mga]

@ionenwks That's a good call. Here are the build flags used on Fedora (as of Fedora 38 on my VM, but it's likely similar on F39).

$ rpm --eval %build_cflags
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 

$ rpm --eval %build_cxxflags
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 

$ rpm --eval %build_ldflags
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1

[ZwieBit]

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.

[novalis]

(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.c looks 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):

• A single thread cannot be both the the event-reading and the
• reply-reading thread at the same time.

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. XGetWindowProperty is another possible culprit (the ones in screen_get_usable_rect only) . 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.

[Lamby777]

@Lamby777 Upgrading libx11 works, too. I compiled and installed the latest libx11 from master on fedora 39 by doing

https://gitlab.freedesktop.org/xorg/lib/libx11/-/tree/master

./autogen.sh ./configure --prefix=/usr make sudo make install

and then reboot and I haven't had a crash yet.

it's been annoying me so much that i finally decided to go looking for this thread again... :P

sadly, it doesn't work :(

Not that compiling your own version doesn't work; that I don't know. The actual compiling part doesn't work. I tried ./autogen.sh and it was giving some error about xorg macros not being installed so i installed this package called xorg-util-macros and now it's complaining about some macro XTRANS_CONNECTION_FLAGS being possibly undefined... Is the macro package I installed just outdated? Cuz i just pulled libx11 source from master so maybe they changed some macros that haven't been put onto arch repos yet. Is that even the right package to install? Seems to be, since the error's gone, but idk

[Lamby777]

At least the error message apologizes, which I found somewhat amusing.

[imaducklol]

I'll add another data point I guess, got the same crash on two different machines:
Godot 4.2.1, Fedora 39 (Gnome 45 on Wayland), libX11 1.8.7, i3-12100F, 5700xt, (Running godot under xwayland)
Godot 4.2.1, Arch (Gnome 46 on Xorg), libX11 1.8.9, i7-1185G7, Iris Xe, (Running godot under xorg)

Happened on both machines at around twice per hour. Wasn't able to pick up on anything specifically that caused them.
I'll report back if I compile libX11 from source and that fixes anything.