Closed protodrew closed 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
@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?
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.
@Liemaeu this really looks like a distro issue.
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.
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.
@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
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
@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.
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)
Unrelated, but that patch also makes the same crash on gamescope. So it's not just godot
And that same patch also crashes vkQuake.
so... It looks like this is not godot's issue, right? Should we close it or keep it open?
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.
opensuse have already fixed it as of 5 hours ago https://build.opensuse.org/package/show/openSUSE:Factory/libX11
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.
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
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).
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
Issue seems to be resolved with upgrade to openSUSE Tumbleweed 20221205-0 -> 20221206-0
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) :-(
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?
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.
Assuming 'note sure' is a typo for 'not sure'?
Anyway good to see it's fixed
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:
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
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
Fixed [Archlinux], I had to install downgrade with:
$ paru -Syu --noconfirm downgrade
$ sudo downgrade libx11
-> and select the version libx11-1.8.2-2
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
Looks like on arch it is already fixed
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.
So, what's the status of this issue? Should it be considered still open?
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
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.
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.
@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.
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)
Downgrade to libx11 1.7.5, or build it with --disable-thread-safety-constructor
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.
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
libx11 now at 1.8.3-5 on Arch. Everything works so far on Godot 4 beta 10.
Still experiencing crashes in godot 4 beta 10 on 1.8.3-5 on arch. So bug tracker issue is reopened over there
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.
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.
Latest upstream version ba548ed1 (libX11-9999.ebuild
) works fine on Gentoo
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.
Ok, seems like they have been merged upstream too.
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:
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.
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)
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.
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