godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.3k stars 21.05k forks source link

Crash on Linux after libX11 update with: [xcb] Unknown sequence number while processing queue (libX11 1.8.3 or 1.8.2 + X-IfEvent patch) #69352

Closed protodrew closed 1 year ago

protodrew commented 1 year ago

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.


Godot version

v4.0.beta6.official.7f8ecffa5

System information

OpenSuse, Intel Iris XE, Wayland, Gnome

Issue description

Trying to launch the godot beta 6 and it hangs upon opening menu or crashes outright.

Godot Engine v4.0.beta6.official.7f8ecffa5 - https://godotengine.org
libdbus-1.so: cannot open shared object file: No such file or directory
libdbus-1.so: cannot open shared object file: No such file or directory
OpenGL Renderer: Mesa Intel(R) Xe Graphics (TGL GT2)

[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
Godot_4_b6.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Steps to reproduce

Attempt to launch Godot 4 beta 6 on opensuse tumbleweed with wayland and gnome. I am using a framework laptop with 11th gen i5, and latest drivers for everything

Minimal reproduction project

n/a

clayjohn commented 1 year ago

@Riteo May have some insight here. It looks like maybe your system can't fall back to X11 which is the only windowing library we support on linuxbsd right now. Riteo is in the process of adding wayland support and making the whole experience better for both X11 and Wayland

Riteo commented 1 year ago

@clayjohn Although I plan to improve X11 substantially, I don't have yet that much experience with it and I don't know why this error happens. That said, the "this is not your fault" really worries me. Perhaps it's a weird OS-side issue? @protodrew do you encounter this issue on any other X11 program?

Liemaeu commented 1 year ago

Same issue here, openSUSE Tumbleweed, X11, KDE Plasma, Nvidia 525.60.11 driver. Didn't have this issue with Godot 4 before, only after updating my os yesterday.

[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
Godot_v4.0-beta6_linux.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

or sometimes

[xcb] Too much data requested from _XRead
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
Godot_v4.0-beta6_linux.x86_64: xcb_io.c:833: _XRead: Assertion `!xcb_xlib_too_much_data_requested' failed.

or

X Error of failed request:  BadImplementation (server does not implement operation)
  Major opcode of failed request:  20 (X_GetProperty)
  Serial number of failed request:  335
  Current serial number in output stream:  335
[xcb] Too much data requested from _XRead
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
Godot_v4.0-beta6_linux.x86_64: xcb_io.c:833: _XRead: Assertion `!xcb_xlib_too_much_data_requested' failed.
Riteo commented 1 year ago

@Liemaeu this really looks like a distro issue.

Liemaeu commented 1 year ago

I recovered the snapshot from before I updated my os, works again.

Strangely only Godot 4 was affected (tried Beta 5, too), Godot 3.5 kept working.

Not sure if it's relevant data/the error causing package, but with libX11-xcb1 version 1.8.2-1.1 it's working, after updating the os (with it libX11-xcb1 to version 1.8.2-2.1) it's not working anymore.

aaschmitz commented 1 year ago

Same issue for me, OpenSUSE Tumbleweed, X11, KDE Plasma 5.26.3, Nvidia 525.60.11 driver, but using Godot 3.5.1.

The editor sometimes opens and crashes/closes after a few minutes, sometimes it doesn't even open the editor, other times it crashes/closes when running the game.

The issue started after the libX11-xcb1 version 1.8.2.x update, /var/log/messages show the entry:

kwin_core: XCB error: 152 (BadDamage), sequence: 31178, resource id: 10499075, major code: 143 (DAMAGE), minor code: 3 (Subtract)

Tried the Godot 3.5.1 from Official Site, the Steam Version, running it via Wine, all have the same issue. The only version that works now is Godot Flatpak.

Riteo commented 1 year ago

@aaschmitz do all other X11 programs work?

btw, this is the changelog of the opensuse package, version 1.8.2:

- Update to version 1.8.2
  * This is primarily a bug fix release, including further work on
    improving the thread-safety-constructor and making it work with
    software which had incorrectly called libX11 functions from
    inside X*IfEvent() calls.
- supersedes U_fix-a-memory-leak-in-XRegisterIMInstantiateCallback.patch
akien-mga commented 1 year ago

Please report the bug to OpenSUSE and provide the information about which package caused the regression, so they can assign the package maintainer to look into it.

I have libX11 1.8.2 on Mageia 9 and no such problem. OpenSUSE seems to have a custom patch they added to fixed apparent regressions in Firefox, and this seems to have broken Godot: https://build.opensuse.org/package/show/openSUSE%3AFactory/libX11

aaschmitz commented 1 year ago

@Riteo Using several programs on X11 and I haven't noticed any other issues, it looks like only Godot is affected by this update to OpenSuse Tumbleweed.

ionenwks commented 1 year ago

Started hitting the same thing on ~testing Gentoo, traced it back to this libX11 patch which seems also used by OpenSUSE, not that anything but godot is giving me issues. Unclear if the problem is the patch or misuse somewhere that happened to work by accident.

https://github.com/gentoo/gentoo/blob/eeb3b760c603/x11-libs/libX11/files/libX11-1.8.2-reentrancy.patch https://build.opensuse.org/package/view_file/openSUSE:Factory/libX11/U_Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch Edit: perhaps more distros/people are also using or considering this backport given it helps with a freezing issue in firefox when using libX11-1.8.2 (probably best stick to 1.8.1 for now)

ionenwks commented 1 year ago

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/170

llyyr commented 1 year ago

Unrelated, but that patch also makes the same crash on gamescope. So it's not just godot

bubbleguuum commented 1 year ago

And that same patch also crashes vkQuake.

Riteo commented 1 year ago

so... It looks like this is not godot's issue, right? Should we close it or keep it open?

akien-mga commented 1 year ago

We can keep it open so that affected users can find it. But yes it's something that needs to be fixed in libX11 / distro packages.

llyyr commented 1 year ago

opensuse have already fixed it as of 5 hours ago https://build.opensuse.org/package/show/openSUSE:Factory/libX11

bubbleguuum commented 1 year ago

It's not fixed as the problematic patch is still in the .spec file: U_Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch

As I understand it, it was added to fix another issue (copy/paste in Firefox I believe).

Also see this issue for further discussion in this hairy situation: http://bugzilla.opensuse.org/show_bug.cgi?id=1205818

The end of this thread is about vkQuake, but this is the same issue affecting Godot.

llyyr commented 1 year ago

It's not fixed as the problematic patch is still in the .spec file: U_Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch

no, it's fixed. the patch is for thread safety constructor which is disabled at build time now. Even if the patch is applied the file isn't built anyway

bubbleguuum commented 1 year ago

Except that according to my test, disabling the safety constructor does not fix this crash at all. At least on vkquake. That's on a fresh libX11 1.8.2 compile with the problematic patch applied (https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/a9e845809bcaae22496bc8aa3ca252b410d5f39b) and configure option --disable-thread-safety-constructor. With stock v1.8.2, it does not crash (vkquake, did not test Godot).

ionenwks commented 1 year ago

Yeah I gave it a quick try on Gentoo and the --disable option doesn't help godot if the patch is still applied, removing the patch or using libX11-1.8.1 works fine (simply removing would bring back firefox crashes though, maybe the --disable option still helps with that but not something I looked into). Edit: although could be missing something that let this work on opensuse's build, haven't tried it

adventureronaquest commented 1 year ago

Issue seems to be resolved with upgrade to openSUSE Tumbleweed 20221205-0 -> 20221206-0

bubbleguuum commented 1 year ago

It reverted to 1.8.1 + some patches but without the problematic patch, so yes it does not crash anymore:

- Update to version 1.8.1
  This release fixes the --enable-thread-safety-constructor option to the
  configure script to work as intended.  In the previous release, the changes
  for this option may not have been enabled when the option was not specified
  or when the --enable option was specified.
  While we have enabled it by default, believing that doing so will reduce
  the number of bugs users encounter running libX11 clients, in some cases
  it may expose bugs in which clients had previously gotten away with calling
  libX11 functions while a libX11 lock is already held, and thus now deadlock,
  as discussed in https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157  
- let's hope this version doesn't suffer yet from the regressions
  reported in boo#1205778, boo#1205818 (reported against 1.8.2);
  we need libX11 thread safe for totem (GNOME 43) :-(
Riteo commented 1 year ago

in some cases it may expose bugs in which clients had previously gotten away with calling libX11 functions while a libX11 lock is already held, and thus now deadlock, as discussed in https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157

well, this is our fault too then, isn't it?

bubbleguuum commented 1 year ago

Either that, or a bug in the problematic libX11 commit. Or in the very worst case, both. Not sure I would agree with a patch in libX11 breaking (crashing) existing programs is the right thing to do, even if it expose some problem in said programs.

Zireael07 commented 1 year ago

Assuming 'note sure' is a typo for 'not sure'?

Anyway good to see it's fixed

aaschmitz commented 1 year ago

With OpenSUSE Tumbleweed 20221206-0, the packages below are downgraded:

libX11-6 libX11-6-32bit libX11-data libX11-xcb1 libX11-xcb1-32bit

Now the Godot 3.5.1 are working fine again :+1:

ionenwks commented 1 year ago

ftr patch was a backport, upstream bug didn't get attention so it's now included in the now-released vanilla libX11-1.8.3 which doesn't seem to play well with godot still from a quick try

Khhs167 commented 1 year ago

This issue has been reported in numerous other places, and seems to have been fixed just an hour ago as of writing this

https://github.com/ValveSoftware/Dota-2/issues/2218 https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/176 https://bugs.archlinux.org/task/76860#comment213715

Correction: A PR with a fix opened an hour ago

rafael-arreola commented 1 year ago

Fixed [Archlinux], I had to install downgrade with:

$ paru -Syu --noconfirm downgrade

$ sudo downgrade libx11

-> and select the version libx11-1.8.2-2

developomp commented 1 year ago

Alternatively, you can also run

sudo pacman -U https://archive.archlinux.org/packages/l/libx11/libx11-1.8.2-2-x86_64.pkg.tar.zst

Just remember to add libx11 to the ignore list

underdoeg commented 1 year ago

Looks like on arch it is already fixed

developomp commented 1 year ago

Looks like on arch it is already fixed

Yup. Tested Godot_v4.0-beta8_mono_linux_x86_64 with libx11 1.8.3-3 and the issue seems to be fixed.

Riteo commented 1 year ago

So, what's the status of this issue? Should it be considered still open?

llyyr commented 1 year ago

It's "fixed" by distros (Arch) patching in PRs that aren't merged upstream yet (and might not even get merged) because they make crashes elsewhere, so this issue should probably stay open until it works without every distro rolling up their own patches

akien-mga commented 1 year ago

Yeah we should wait for an official upstream fix to be consistently deployed to all distros before closing. Despite it being open we had 5 duplicate bug reports, 2 of them even after we've pinned this issue.

But there's nothing to do from our side, this is just open for user information.

Megalomaniak commented 1 year ago

I don't see anyone mentioning XWayland in here, make sure you have it installed. That's what allows for X11 applications to run in wayland environments.

Riteo commented 1 year ago

@Megalomaniak without XWayland the X11 code wouldn't run close at all to the problematic part (it'd fail waaaay earlier), so I presume that everyone stumbling on this issue already has it installed.

cg9999 commented 1 year ago

I'm still randomly getting crashes during editor use on fully updated arch linux and godot 4.0 beta 10 / current master dev build.

> bin/godot.linuxbsd.editor.dev.x86_64
Godot Engine v4.0.beta.custom_build.f05fe7454 - https://godotengine.org
OpenGL Renderer: Mesa Intel(R) HD Graphics 620 (KBL GT2)

Editing project: /home/...[removed]
Godot Engine v4.0.beta.custom_build.f05fe7454 - https://godotengine.org
Vulkan API 1.3.230 - Using Vulkan Device #0: Intel - Intel(R) HD Graphics 620 (KBL GT2)

later various types of crashes with xcb:

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

or

godot.linuxbsd.editor.dev.x86_64: xcb_in.c:757: xcb_request_check: Assertion `!reply' failed.

or

[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot.linuxbsd.editor.dev.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

is this the same issue or something related. I haven't yet tried downgrading libx11 (It's currently arch 1.8.3-3, which should be already fixed)

llyyr commented 1 year ago

Downgrade to libx11 1.7.5, or build it with --disable-thread-safety-constructor

Eisendroid commented 1 year ago

It seems like it's still broken. I am on EndeavourOS (Arch) and it got fixed by some update few weeks ago (downgrade?). Today libx11 got pushed to 1.8.3-4 and it's broken again.

akien-mga commented 1 year ago

Arch Linux users, please comment on https://bugs.archlinux.org/task/76860 which is the upstream report.

1.8.3-4 removed the (yet unmerged) upstream patches that solve the issue, to replace them with a (merged) upstream patch. They seem to expect it fixes Godot too, but evidently it doesn't. https://github.com/archlinux/svntogit-packages/commit/27567a0220da86d3c45eb3e341f30457f93d99d7

Eisendroid commented 1 year ago

libx11 now at 1.8.3-5 on Arch. Everything works so far on Godot 4 beta 10.

Khhs167 commented 1 year ago

Still experiencing crashes in godot 4 beta 10 on 1.8.3-5 on arch. So bug tracker issue is reopened over there

cg9999 commented 1 year ago

Still experiencing crashes in godot 4 beta 10 on 1.8.3-5 on arch. So bug tracker issue is reopened over there

Same here. -4 was completely broken. Either hang or crash at startup, but -5 is back to random crashing behaviour.

Megalomaniak commented 1 year ago

lib32-libx11 1.8.3-1.0 update that I was greeted with this morning on Manjaro Testing seems to have resolved it for me.

LinuxUserGD commented 1 year ago

Latest upstream version ba548ed1 (libX11-9999.ebuild) works fine on Gentoo

```bash # Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 XORG_DOC=doc XORG_MULTILIB=yes XORG_TARBALL_SUFFIX=xz inherit toolchain-funcs xorg-3 git-r3 # Note: please bump this with x11-misc/compose-tables DESCRIPTION="X.Org X11 library" EGIT_REPO_URI="https://gitlab.freedesktop.org/xorg/lib/libx11" KEYWORDS="" IUSE="test" RESTRICT="!test? ( test )" RDEPEND=" >=x11-libs/libxcb-1.11.1[${MULTILIB_USEDEP}] x11-misc/compose-tables !
ionenwks commented 1 year ago

Latest upstream version ba548ed1 (libX11-9999.ebuild) works fine on Gentoo

Gentoo has backported fixes in libX11-1.8.3-r1 which afaik works fine.

LinuxUserGD commented 1 year ago

Ok, seems like they have been merged upstream too.

akien-mga commented 1 year ago

lib32-libx11 1.8.3-1.0 update that I was greeted with this morning on Manjaro Testing seems to have resolved it for me.

I'm a bit confused by the versioning here, how does 1.8.3-1.0 compare to 1.8.3-5 from stock Arch repos?

The lib32-libx11 and libx11 packages seem weirdly out of sync: image

How is lib32-libx11 used exactly? Isn't that only the 32-bit equivalent of libx11, and thus used only if you run a 32-bit build of Godot?

Gentoo has backported fixes in libX11-1.8.3-r1 which afaik works fine.

That's interesting because this package backports the same two patches as Arch Linux's 1.8.3-5, yet users are reporting that this one still crashes intermittently. Please let us know if you do experience intermittent crashes eventually pointing at X11 stuff.

ionenwks commented 1 year ago

Gentoo has backported fixes in libX11-1.8.3-r1 which afaik works fine.

That's interesting because this package backports the same two patches as Arch Linux's 1.8.3-5, yet users are reporting that this one still crashes intermittently. Please let us know if you do experience intermittent crashes eventually pointing at X11 stuff.

Don't know if it's really fixed (I haven't tested enough to pickup intermittent crashes if they're rare), but Arch has an older version of the PR and isn't the same as what has been merged upstream or used by Gentoo.

e.g. 176.diff adds

+    if (dpy->in_ifevent && dpy->ifevent_thread == xthread_self())
+        return;

while libX11-1.8.3-reentrancy-again.patch instead does:

+    if (dpy->in_ifevent && xthread_equal(dpy->ifevent_thread, xthread_self()))
+        return;

(Edit: not familiar enough with libX11 to know if these differences can have an impact for Godot, but if the equal tests fail I'd assume it'd be bad)