I use fvwm on my system and except of #852194 X was usable so far. But when I upgrade from x11-libs/libX11-1.7.5 to x11-libs/libX11-1.8.1, an modale dialog like pinentry will kill all X in a subtile manner. The X is still running and the xterm that had the focus is still there and has the focus. However, no other window is able to get the focus. And when I kill pinentry, the window will be still there (but without focus.) Downgrading to 1.7.5 does fix the problem. Maybe that bug is related to#852194. Reproducible: Always
See also bug #1016363 on debian. The bug happens there too.
Could you possibly bisect libX11 to see which commit causes it?
How to do this on gentoo? If I change the ebuild in /usr/portage, emerge will not build it anymore as all the signatures will be invalid.
(In reply to Klaus Ethgen from comment #3) > How to do this on gentoo? If I change the ebuild in /usr/portage, emerge > will not build it anymore as all the signatures will be invalid. Few options: 1. Copy it into a local overlay and do modifications there; 2. Change it in /usr/portage and run "ebuild ... digest" after changing it; 3. Build manually (not ideal). I have another option (we have no live ebuild for libX11 which would make it much easier to bisect): what about using 1.7.5 and applying in /etc/portage/patches each of the commits up until 1.8.1?
The solution with the patches sounds doable. Do you have a git repository of libX11?
(In reply to Klaus Ethgen from comment #5) > The solution with the patches sounds doable. > > Do you have a git repository of libX11? Sure! https://gitlab.freedesktop.org/xorg/lib/libx11.git. What you can do is actually bisect like normal in that repo: 1. git clone https://gitlab.freedesktop.org/xorg/lib/libx11.git 2. git bisect start 3. git bisect bad libX11-1.8.1 4. git bisect good libX11-1.7.5 5. It will give you a repo state which you need to test. Run 'git format-patch libX11-1.7.5..HEAD --stdout > /etc/portage/patches/x11-libs/libX11/test-bisect.patch', then emerge -v1 x11-libs/libX11. If it works, run 'git bisect good'. If it doesn't, run 'git bisect bad'. Repeat until we find the first bad commit. And let's pray it works out okay like this and they didn't e.g. change the build system too much :)
I found it. But how to tell emerge to not use a binary package when getbinpkg is in place? I usually build the packages on a build server.
(In reply to Klaus Ethgen from comment #7) > I found it. But how to tell emerge to not use a binary package when > getbinpkg is in place? I usually build the packages on a build server. emerge --usepkg=n ..., can even do emerge --usepkg=n --getbinpkg=n, etc, or even emerge --ignore-default-opts ...
emerge --usepkg=n didn't work but FEATURES="-getbinpkg" emerge ... Why is there a =n when it is not respected?
(In reply to Klaus Ethgen from comment #9) > emerge --usepkg=n didn't work but FEATURES="-getbinpkg" emerge ... > > Why is there a =n when it is not respected? Because usepkg != getbinpkg. Did you try --getbinpkg=n?
afcdb6fb0045c6186aa83d9298f327a7ec1b2cb9 is the patch that broke it!
(In reply to Klaus Ethgen from comment #11) > afcdb6fb0045c6186aa83d9298f327a7ec1b2cb9 is the patch that broke it! Nice work! Now, there's a complication here, because that patch had a quoting error in configure.ac (was discussed a tiny bit in bug 841857). Can you try EXTRA_ECONF="--enable-thread-safety-constructor" emerge -v1 libX11 with vanilla (no patches) 1.8.1?
As I can see, the bug is fixed in 70f7403fd3bf but without the broken afcdb6fb0045, there is no reason to fix it as this commit did introduce that quoting bug too. But however, I'll try.. Stand by.
As expected, same error
(In reply to Klaus Ethgen from comment #13) > As I can see, the bug is fixed in 70f7403fd3bf but without the broken > afcdb6fb0045, there is no reason to fix it as this commit did introduce that > quoting bug too. > > But however, I'll try.. Stand by. Sorry, I think I meant --disable-thread-safety-constructor.
I already anticipated that. the disable does make the bug gone away as it removes the whole broken part from patch afcdb6fb0045.
(In reply to Klaus Ethgen from comment #16) > I already anticipated that. > > the disable does make the bug gone away as it removes the whole broken part > from patch afcdb6fb0045. Right, that's why I asked, I just wanted to be sure. It's also a better workaround than using an old version. I've mentioned this on the upstream bug at https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157#note_1490190. But it's likely to be a fvwm bug.
… and a xfce bug? Or to be said: A bug of anything except gnome on wayland? About the gitlab comment, I cannot read it as proejcts on gitlab always refuses to give some content. no commits, no issues, no nothing.
(In reply to Klaus Ethgen from comment #18) > … and a xfce bug? Or to be said: A bug of anything except gnome on wayland? > I don't want to get into things like that. There was a commit to fix Xfce because it was taking a lock twice (so it hangs). That patch was merged into Xfce (https://gitlab.xfce.org/xfce/xfce4-settings/-/commit/55a823abae8827eb33718eb59b3d3fee1de4f901). Nobody disputed Xfce had a bug there (including Xfce upstream). My guess is there's something else, this time in fvwm, which violates one of the thread assumptions. I don't know enough about fvwm or libX11 to debug further. It's possible that -fsanitize=thread would help locate a double lock, not sure. I would report to fvwm upstream if they still support the original version. But maybe the X11 folks will help out like they did with XFCE. > About the gitlab comment, I cannot read it as proejcts on gitlab always > refuses to give some content. no commits, no issues, no nothing. It requires JavaScript.
> It requires JavaScript. Ok, that clarifies why it doesn't work since many months. I never allow javascript. Pages that does not work without are broken. Well, if a possible way to make something thread safe breaks it in many situations would mean that it is not thread safe. So it IS a libX11 bug.
(In reply to Klaus Ethgen from comment #20) > Well, if a possible way to make something thread safe breaks it in many > situations would mean that it is not thread safe. So it IS a libX11 bug. That's not how it works if things are disobeying an API contract. Anyway, there's a patch for fvwm3: https://github.com/fvwmorg/fvwm3/commit/5c17c83df4605d2d97999740cf180af983298896. It could be backported to fvwm if someone is interested. There's also https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/150 which is a workaround for buggy applications.
It might make sense to have fvwm-2.6.9 (and other packages that have similar bugs) block libX11-1.8.1, since both are stable but don't work together?
(In reply to Daniel Barkalow from comment #22) > It might make sense to have fvwm-2.6.9 (and other packages that have similar > bugs) block libX11-1.8.1, since both are stable but don't work together? Alternaitvely, we add USE=thread-safety-constructor & depend on it (or maybe a less clunky name). I wasn't sure if upstream were going to release a workaround with something like https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/150 but that's not happened yet.
Sam: Not in a position to test this quickly, but do you think this also impacts x11-wm/fvwm3? I could be persuaded to cherry pick the patch when I look into some ebuild stuff this week for a `-r#` bump.
Off-topic with the current issue topic, but very related to the specific version of libX11: Just wanted to add that also xhost has problems with libX11 1.8.1: xhost: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed. Downgrading to libX11 1.7.5 fixes the problem. PS! Found no issues upstream, but maybe https://gitlab.freedesktop.org/xorg/app/xhost isn't the place to look.
(In reply to Hans F. Nordhaug from comment #25) > Off-topic with the current issue topic, but very related to the specific > version of libX11: > > Just wanted to add that also xhost has problems with libX11 1.8.1: > > xhost: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: > Assertion `e != ESRCH || !robust' failed. > > Downgrading to libX11 1.7.5 fixes the problem. > > PS! Found no issues upstream, but maybe > https://gitlab.freedesktop.org/xorg/app/xhost isn't the place to look. That is the correct location. Please file an issue there and I'll keep an eye on it.
I believe this should have been fixed by https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=79775575418fd6f8ee1c5e5bbe403df4606fb5b6 which is in v1.8.2. Could someone confirm?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eeb3b760c6031ad77d1deeceef1d5cca3714a6d4 commit eeb3b760c6031ad77d1deeceef1d5cca3714a6d4 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-25 06:04:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-25 06:04:05 +0000 x11-libs/libX11: backport another reentrancy fix Closes: https://bugs.gentoo.org/862115 Signed-off-by: Sam James <sam@gentoo.org> .../libX11/files/libX11-1.8.2-reentrancy.patch | 149 +++++++++++++++++++++ x11-libs/libX11/libX11-1.8.2-r1.ebuild | 48 +++++++ 2 files changed, 197 insertions(+)
