-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
it's been annoying me so much that i finally decided to go looking for this thread again... :P 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: ***@***.***>
|
1.8.10 - Broken. I have been struggling with this very same crash for some time now in my personal project and have also resorted to trying to create an MRP to force the crash. The intent being that if I could find a force for the crash, Godot's developers could maybe use that information to find a workaround. So far, no luck in forcing it. Will continue to attempt it though. Also, so far I have been unable to eradicate it completely from my project with workarounds. Although I do think I have managed to reduce the occurrence rate. But this could just be a feeling. As the crash is very random in nature. Very hard to predict and to reproduce. |
One thing I have noticed while struggling with finding a workaround or MRP to force the crash is that I have yet to see it happen with the editor or the running project being in focus. I have seen both the running project as well as the editor itself (without the project running) crash as a result of this issue but never when in focus. Always when focus was on a different task. Most recent crash I've had was with Godot being open, my project not running and me just working on some C# code for the project, using an external editor (VSCode). And any time my project itself runs into this crash it is with the project not being in focus. Maybe this could help to guide someone more familiar with the interaction between Godot and the crashing library towards a workaround. For example, is there something different between how Godot updates/draws windows which are in focus compared to how it updates/draws windows which are not in focus? |
The editor is capped to 10 FPS by default when unfocused. You can disable this behavior by enabling Update Continuously in the Editor Settings. (This disables the effect of the Low Processor Mode Sleep Usec and Unfocused Low Processor Mode Sleep Usec editor settings.) |
I haven't seen the editor crash since enabling this. It's been a total uptime of at least a few dozen hours by now. So, it would appear there is something to the crash being more likely to happen with infrequently updated windows or windows with a lower frame rate. But, this is hardly a viable workaround. As per the tooltip of this option, it is more to be used for troubleshooting purpses. Incidentally, is there something else about projects run in the background versus in focus? Like, some internal optimization the engine performs to save on CPU/GPU cycles for unfocused windows? So, not related to the editor but related to the engine itself. |
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: