Project or editor crashes randomly from xcb XInitThreads #75308
Comments
|
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). |
|
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"). |
|
Saw this happening (only once) on a totally different config: |
|
I have this too, again. Seems very reminiscent of #69352 Godot: v4.0.1.stable.arch_linux |
|
Manjaro kernel version: 6.1.22-1 Managed to reproduce it when connected to gdb, adding backtrace as the attachment Forgot to mention Godot version: custom build based on 4.0.2 stable |
|
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: |
|
Having the same issue, Manjaro with Hyprland / Wayland here. Also Godot 4.0.1 stable, libx11 v1.8.4-1, intel integrated graphics. |
|
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? |
|
Same issue. |
|
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 |
|
Just had this happen swaywm |
|
I'm getting the same error, with a recent libX11 and non-Arch Linux Godot Engine v4.1.1.stable.custom_build Void Linux |
|
Confirmed on Fedora running KDE with Mesa Intel® Xe Graphics. |
|
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 :-) |
|
I am having similar crashes involving Ubuntu 23.04 The error messages are as follow:
or
or
It also sometimes crashes without an error message. |
|
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.
|
|
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 |
|
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. ;-; |
|
@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
and then reboot and I haven't had a crash yet. |
|
Gonna share I'm experiencing this regularly on my Manjaro KDE machine. Currently working with Godot 4.2-Stable running it from the command line so I get more interesting details. Error from terminal: |
|
System info... Error in terminal... |
That's weird, as the latest 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. |
|
|
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). |
|
@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). |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
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. |
|
(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 But consider the following rule (from
So we would expect the call to So it seems possible that there's a race there. I have only read the code, so this could be totally bogus. But it seems plausible. |
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 |
|
At least the error message apologizes, which I found somewhat amusing. |
|
I'll add another data point I guess, got the same crash on two different machines: Happened on both machines at around twice per hour. Wasn't able to pick up on anything specifically that caused them. |
|
Don't know if it's useful, but here is a new repro:
Debian 12 If any other info is needed, I can edit this post. |
|
That version is almost five years old. Is it possible that we're looking at some ABI incompatibility here? |
That's a good question. This hypothesis could be tested by someone who can reproduce the issue reliably, by making a custom build with |
|
Before I read your comment, I tried another track: I replaced the vendored I can reproduce it fairly reliably at the moment: my game usually crashes within tens of seconds. The editor fares better, but also crashes about once an hour or so. With For the record, here are the commands I used to build (it gets simpler without mono): |
|
Summarizing the reports above:
The only difference between 1.8.5 and 1.8.6 is 304a654, which seems unrelated to me. So I'm inclined to assume that there was only one breakage, not two, and 1.8.5 is broken as well. I tried rebuilding the Arch package from the official PKGBUILD. Even with this, I could not trigger the crash! So for Arch users, this is a local workaround. After reinstalling the official binary package, I got a crash within a minute or two. The two --- official-xcb.hex 2024-05-29 12:23:39.711349095 +0200
+++ mine-xcb.hex 2024-05-29 12:23:45.944791641 +0200
@@ -45,8 +45,8 @@
000002c0: 0300 0000 0000 0000 0100 01c0 0400 0000 ................
000002d0: 0100 0000 0000 0000 0200 01c0 0400 0000 ................
000002e0: 0000 0000 0000 0000 0400 0000 1400 0000 ................
-000002f0: 0300 0000 474e 5500 cf41 1b11 8b82 2d5d ....GNU..A....-]
-00000300: ad43 7b2d 9bad ab79 884a bc70 0000 0000 .C{-...y.J.p....
+000002f0: 0300 0000 474e 5500 7e7a c198 eaf0 26ab ....GNU.~z....&.
+00000300: 1636 87ec 7be5 6f04 a5b9 943b 0000 0000 .6..{.o....;....
00000310: 0200 0000 0500 0000 0100 0000 0600 0000 ................
00000320: 0000 0200 0005 0008 0500 0000 0600 0000 ................
00000330: 6be4 cc2e 3b9a cb9a 0000 0000 0000 0000 k...;...........
@@ -767,10 +767,10 @@
00002fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00002ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00003000: 0040 0000 0000 0000 4743 433a 2028 474e [email protected]: (GN
-00003010: 5529 2031 332e 322e 3120 3230 3233 3038 U) 13.2.1 202308
-00003020: 3031 0000 6c69 6258 3131 2d78 6362 2e73 01..libX11-xcb.s
+00003010: 5529 2031 342e 312e 3120 3230 3234 3035 U) 14.1.1 202405
+00003020: 3037 0000 6c69 6258 3131 2d78 6362 2e73 07..libX11-xcb.s
00003030: 6f2e 312e 302e 302e 6465 6275 6700 0000 o.1.0.0.debug...
-00003040: 164f e2c3 002e 7368 7374 7274 6162 002e .O....shstrtab..
+00003040: fdef bdc9 002e 7368 7374 7274 6162 002e ......shstrtab..
00003050: 6e6f 7465 2e67 6e75 2e70 726f 7065 7274 note.gnu.propert
00003060: 7900 2e6e 6f74 652e 676e 752e 6275 696c y..note.gnu.buil
00003070: 642d 6964 002e 676e 752e 6861 7368 002e d-id..gnu.hash..This does give a clue: apparently the official binary package was compiled with GCC 13.2.1, whereas I'm using GCC 14.1.1. This explains the differences in Not being able to reproduce this in my own build, even before adding debug information, makes this thing very hard to debug, but I'll keep trying. |
|
I installed the Something I found in the core dump: at the time of the crash, there were two threads interacting with xcb. The main thread, that aborted: And a thread that appears to belong to AMD's Vulkan driver: The latter is hanging in a |
|
Line numbers refer to libx11 1.8.9, although the file On line 319 in There is no code that modifies the And the first thing that function does, is to fail the assertion: Since It should be noted that we are in an There are only two such places that matter: When continuing the program after the breakpoint is hit, it immediately crashes apologetically. The API function This is as far as I got for today. I tried setting more breakpoints in |
|
Hey, this seems to still be an issue running on Ubuntu 24.04 running x11 and KDE. Godot Engine v4.3.stable.official.77dcf97d8 - https://godotengine.org
Vulkan 1.3.274 - Forward+ - Using Device #0: Intel - Intel(R) UHD Graphics (ICL GT1)
[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
project.x86_64: ../../src/xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Aborted (core dumped)I wonder if this is an intel integrated graphics thing? Also should I try and update something to fix this? |
|
It's not specific to Intel -- I have an AMD Radeon and I get it.
Nobody seems to have found a fix yet, so don't bother updating anything.
…On November 17, 2024 1:27:52 PM EST, some1and2 ***@***.***> wrote:
Hey, this seems to still be an issue running on Ubuntu 24.04 running x11 and KDE.
```sh
Godot Engine v4.3.stable.official.77dcf97d8 - https://godotengine.org
Vulkan 1.3.274 - Forward+ - Using Device #0: Intel - Intel(R) UHD Graphics (ICL GT1)
[xcb] Unknown request in queue while dequeuing
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
project.x86_64: ../../src/xcb_io.c:175: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Aborted (core dumped)
```
I wonder if this is an intel integrated graphics thing? Also should I try and update something to fix this?
--
Reply to this email directly or view it on GitHub:
#75308 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
and others
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:
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
The text was updated successfully, but these errors were encountered: