Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1111449 > unrolled thread

Bug#1016363: libx11 v1.8.1 does fail in a subtle way withj modale dialogs

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1016363: libx11 v1.8.1 does fail in a subtle way withj modale dialogs Klaus Ethgen <Klaus@ethgen.de> - 2022-07-30 07:40 +0200
    Bug#1016363: libx11-6 1.8.1 also breaks notion Göran Weinholt <goran@weinholt.se> - 2022-07-30 13:10 +0200
    Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1 Max Bell <mbell@pobox.com> - 2022-07-31 02:40 +0200
    Bug#1016363: libx11-6 1.8.1 also breaks glxinfo Hermann Meyer <brummer-@web.de> - 2022-08-01 15:10 +0200
      Bug#1016363: libx11-6 1.8.1 also breaks glxinfo gregor herrmann <gregoa@debian.org> - 2022-08-03 20:40 +0200
    Bug#1016363: libx11-6 1.8.1 also breaks glxinfo Max Bell <mbell@pobox.com> - 2022-08-03 20:40 +0200
      Bug#1016363: libx11-6 1.8.1 also breaks glxinfo Michel Dänzer <michel.daenzer@mailbox.org> - 2022-08-04 10:40 +0200
      Bug#1016363: libx11-6 1.8.1 also breaks glxinfo "Richard B. Kreckel" <kreckel@in.terlu.de> - 2022-08-04 12:40 +0200

#1111449 — Bug#1016363: libx11 v1.8.1 does fail in a subtle way withj modale dialogs

[Multipart message — attachments visible in raw view] — view raw

Package: libx11-6
Version: 2:1.8.1-1
Severity: critical

When upgrading libx11 from 2:1.7.5-1 to 2:1.8.1-1 X will fail in a very
strange way immediately when a modal dialog starts (like pinentry).

I use fvwm and have focus follow mouse. When pinentry starts, the focus
still stays on the window that I use before. (xterm) But there is no way
anymore to change focus. Even more, when killing the pinentry, the
process is gone but the window is still on the screen. The whole X is
fully infunctional afterwards.

The only solution is to kill (-9) the whole X stack. A simple kill
(-TERM) will not end the dysfunctional X session.

Going back to libx11 2:1.7.5-1 solves the problem.

Note, the same bug happens on gentoo. I opened bug #862115 over there
yesterday.

-- System Information:
Debian Release: bookworm/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libx11-6 depends on:
ii  libc6        2.33-8
ii  libx11-data  2:1.7.5-1
ii  libxcb1      1.14-3

libx11-6 recommends no packages.

libx11-6 suggests no packages.

-- no debconf information

-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

[toc] | [next] | [standalone]

#1111457 — Bug#1016363: libx11-6 1.8.1 also breaks notion

Hello,

The libx11 commit "global: call XInitThreads() from the library's
constructor" identified in this issue is also breaking notion.

notion 4.0.2+dfsg-6 with libx11-6 2:1.8.1-1 crashes with this message:

  notion: tpp.c:82: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)' failed.

I rebuilt libx11 with the new --disable-thread-safety-constructor flag
and then notion started working again.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

[toc] | [prev] | [next] | [standalone]

#1111508 — Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1

Assuming this issue effects only one app is defective. Fix the broken
compatibly with legacy code as this solves it for all programs. And
does not require rewriting an unknown number of apps, that probably
don't have maintainers to fix things, to keep working vs. being
rendered unusable.

On 7/30/22, Jed Davis <jld@xlerb.net> wrote:
> FVWM's problem here appears to be that it calls XCheckIfEvent with a
> callback that ends up trying to call XFlush; XCheckIfEvent holds the display
> lock while calling the callback and XFlush also locks the display, causing a
> self-deadlock.  I provoked this by iconifying a window with a key bind, and
> in this case it seems to have something to do with the resulting expose
> events (see stack below).  This reentrancy may not be ideal behavior on
> FVWM's part, but this is code which has (seemingly) worked for a long time.
>
> I also came up with a different workaround: instead of rebuilding libx11, I
> rebuilt FVWM with the following definition added:
>
> Status XInitThreads(void)
> {
>         return 0;
> }
>
> The executable precedes its libraries in the symbol search path, so this
> turns off X11 thread safety entirely, but only for fvwm; it doesn't appear
> to use threading, either directly or indirectly, and I'm assuming that
> situation isn't likely to change in the immediate future.  This isn't a
> great solution, but it works for me for now.
>
> If it helps, here's the interesting part of the stack trace from the
> deadlock:
>
> #3  0x00007f01a975a968 in _XLockDisplay (dpy=0x55ca735f4090) at
> ../../src/locking.c:466
> #4  0x00007f01a974e5c2 in XFlush (dpy=0x55ca735f4090) at
> ../../src/Flush.c:38
> #5  0x000055ca7248be1b in dispatch_event (e=0x55ca736ec2f8) at
> events.c:4105
> #6  0x000055ca7248c0cc in _pred_weed_handle_expose (display=<optimized out>,
> event=<optimized out>, arg=<optimized out>) at events.c:266
> #7  0x000055ca724ff3b9 in _fev_pred_weed_if (display=<optimized out>,
> event=0x55ca736ec2f8, arg=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:176
> #8  0x000055ca724ff43f in _fev_pred_check_peek (display=<optimized out>,
> event=0x55ca736ec2f8, arg=0x7ffebc686fb0 "p\363Or\312U") at FEvent.c:144
> #9  0x00007f01a97489aa in XCheckIfEvent (dpy=0x55ca735f4090,
> event=event@entry=0x7ffebc686ef0, predicate=predicate@entry=0x55ca724ff420
> <_fev_pred_check_peek>, arg=arg@entry=0x7ffebc686fb0 "p\363Or\312U") at
> ../../src/ChkIfEv.c:59
> #10 0x000055ca724ffdc0 in FCheckPeekIfEvent (display=<optimized out>,
> event_return=event_return@entry=0x7ffebc6870e0,
> predicate=predicate@entry=0x55ca724ff370 <_fev_pred_weed_if>,
> arg=arg@entry=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:590
> #11 0x000055ca724fff17 in FWeedIfEvents (display=<optimized out>,
> weed_predicate=weed_predicate@entry=0x55ca7248c0b0
> <_pred_weed_handle_expose>, arg=arg@entry=0x0) at FEvent.c:527
> #12 0x000055ca7248cfba in handle_all_expose () at events.c:4545
> #13 0x000055ca724be911 in __raise_or_lower_window (t=t@entry=0x55ca7361c250,
> mode=mode@entry=SM_RAISE, allow_recursion=allow_recursion@entry=1,
> is_new_window=is_new_window@entry=0,
> is_client_request=is_client_request@entry=0) at stack.c:1141
>
> --Jed
>
>

[toc] | [prev] | [next] | [standalone]

#1111664 — Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Multipart message — attachments visible in raw view] — view raw

With libx11-6 1.8.1 I get:

|glxinfo name of display: :0 glxinfo: ../nptl/pthread_mutex_lock.c:424:
__pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed.
Abgebrochen|

rebuilding libx11 with the --disable-thread-safety-constructor flag
solved the issue.


|System:   Host: box Kernel: 5.18.0-rt11 arch: x86_64 bits: 64 compiler:
gcc v: 12.1.0     Desktop: Cinnamon v: 5.2.7 Distro: siduction 18.3.0
Patience - cinnamon -     (201805132102) base: Debian GNU/Linux
bookworm/sid Machine:   Type: Desktop System: Dell product: Inspiron
3668 v: N/A     serial: <superuser required>   Mobo: Dell model: 07KY25
v: A00 serial: <superuser required> UEFI: Dell     v: 1.4.0 date:
07/19/2017 CPU:   Info: quad core model: Intel Core i5-7400 bits: 64
type: MCP     arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3:
6 MiB   Speed (MHz): avg: 3300 min/max: 800/3001 boost: enabled cores:
1: 3300     2: 3300 3: 3300 4: 3300 bogomips: 24000   Flags: avx avx2 ht
lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Graphics:   Device-1:
Intel HD Graphics 630 vendor: Dell driver: i915 v: kernel     arch:
Gen-9.5 bus-ID: 00:02.0   Device-2: NVIDIA GP108 [GeForce GT 1030]
vendor: Dell driver: nvidia     v: 470.129.06 arch: Pascal bus-ID:
01:00.0   Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v:
22.1.3 driver:     X: loaded: modesetting,nvidia unloaded:
fbdev,nouveau,vesa gpu: i915,nvidia     resolution: 1920x1080~60Hz|

[toc] | [prev] | [next] | [standalone]

#1111884 — Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Multipart message — attachments visible in raw view] — view raw

On Mon, 01 Aug 2022 14:57:59 +0200, Hermann Meyer wrote:

> With libx11-6 1.8.1 I get:
> 
> |glxinfo name of display: :0 glxinfo: ../nptl/pthread_mutex_lock.c:424:
> __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed.
> Abgebrochen|

Same here.
 
With xscreensaver I also see SIGABRTs:

% /usr/libexec/xscreensaver/xscreensaver-gl-visual 
xscreensaver-gl-visual: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed.
[2]    16090 IOT instruction (core dumped)  /usr/libexec/xscreensaver/xscreensaver-gl-visual


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007fd5dad70546 in __GI_abort () at abort.c:79
#2  0x00007fd5dad7042f in __assert_fail_base (fmt=0x7fd5daee6fb8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fd5da8a969f "e != ESRCH || !robust", file=0x7fd5da8a9682 "../nptl/pthread_mutex_lock.c", line=424, function=<optimized out>) at assert.c:92
#3  0x00007fd5dad7f242 in __GI___assert_fail (assertion=assertion@entry=0x7fd5da8a969f "e != ESRCH || !robust", file=file@entry=0x7fd5da8a9682 "../nptl/pthread_mutex_lock.c", line=line@entry=424, function=function@entry=0x7fd5da8a9800 <__PRETTY_FUNCTION__.1> "__pthread_mutex_lock_full") at assert.c:101
#4  0x00007fd5da89ded3 in __pthread_mutex_lock_full (mutex=0x56356ef69310) at ../nptl/pthread_mutex_lock.c:424
#5  0x00007fd5daf5891a in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fd5daf6af48 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fd5dac47146 in get_socket_back (c=0x56356ef6a760) at ../../src/xcb_out.c:96
#8  get_socket_back (c=0x56356ef6a760) at ../../src/xcb_out.c:87
#9  0x00007fd5dac479de in prepare_socket_request (c=0x56356ef6a760) at ../../src/xcb_out.c:126
#10 send_fds (num_fds=0, fds=0x0, c=0x56356ef6a760) at ../../src/xcb_out.c:196
#11 xcb_send_request_with_fds64 (c=c@entry=0x56356ef6a760, flags=flags@entry=1, vector=vector@entry=0x7ffc68a55b90, req=req@entry=0x7fd5dac5a9e0 <xcb_req>, num_fds=num_fds@entry=0, fds=fds@entry=0x0) at ../../src/xcb_out.c:316
#12 0x00007fd5dac4818b in xcb_send_request64 (c=c@entry=0x56356ef6a760, flags=flags@entry=1, vector=vector@entry=0x7ffc68a55b90, req=req@entry=0x7fd5dac5a9e0 <xcb_req>) at ../../src/xcb_out.c:349
#13 0x00007fd5dac48199 in xcb_send_request (c=c@entry=0x56356ef6a760, flags=flags@entry=1, vector=vector@entry=0x7ffc68a55b90, req=req@entry=0x7fd5dac5a9e0 <xcb_req>) at ../../src/xcb_out.c:355
#14 0x00007fd5dac56d14 in xcb_query_extension (c=c@entry=0x56356ef6a760, name_len=<optimized out>, name=name@entry=0x7fd5da8e7000 "DRI3") at xproto.c:12277
#15 0x00007fd5dac4a272 in get_lazyreply (c=c@entry=0x56356ef6a760, ext=ext@entry=0x7fd5da8e9070 <xcb_dri3_id>) at ../../src/xcb_ext.c:79
#16 0x00007fd5dac4a3c5 in xcb_prefetch_extension_data (c=0x56356ef6a760, ext=0x7fd5da8e9070 <xcb_dri3_id>) at ../../src/xcb_ext.c:111
#17 0x00007fd5da9db2b5 in dri3_x11_connect (dri2_dpy=dri2_dpy@entry=0x56356ef87e30) at ../src/egl/drivers/dri2/platform_x11_dri3.c:558
#18 0x00007fd5da9da498 in dri2_initialize_x11_dri3 (disp=0x56356ef87350) at ../src/egl/drivers/dri2/platform_x11.c:1503
#19 dri2_initialize_x11 (disp=disp@entry=0x56356ef87350) at ../src/egl/drivers/dri2/platform_x11.c:1676
#20 0x00007fd5da9d46c0 in dri2_initialize (disp=0x56356ef87350) at ../src/egl/drivers/dri2/egl_dri2.c:1179
#21 dri2_initialize (disp=disp@entry=0x56356ef87350) at ../src/egl/drivers/dri2/egl_dri2.c:1146
#22 0x00007fd5da9cc79d in eglInitialize (dpy=0x56356ef87350, major=0x7ffc68a55d58, minor=0x7ffc68a55d5c) at ../src/egl/main/eglapi.c:640
#23 0x000056356ea7cccf in get_gl_visual (screen=0x56356ef698b0) at ./utils/visual-gl.c:68
#24 0x000056356ea7c43c in main (argc=<optimized out>, argv=0x7ffc68a55eb8) at ./hacks/glx/xscreensaver-gl-visual.c:79


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   

[toc] | [prev] | [next] | [standalone]

#1111885 — Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

Why isn't the bug being fixed? That is obviously the correct solution.

On 8/3/22, Richard B. Kreckel <kreckel@in.terlu.de> wrote:
> This is issue 157 upstream:
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
> Apparently, they do not want to revert it.
>
> So, should Debian build with --disable-thread-safety-constructor, at
> least for a while?
>
> (Remember that this bug will soon block other packages from migrating,
> e.g. thunderbird 102.)
>
>   -richy.
> --
> Richard B. Kreckel
> <https://in.terlu.de/~kreckel/>
>
>

[toc] | [prev] | [next] | [standalone]

#1111960 — Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

On 2022-08-03 20:33, Max Bell wrote:
> Why isn't the bug being fixed? That is obviously the correct solution.

Not that obviously I'm afraid, e.g. Mesa's zink driver is going to rely on libX11 being built without --disable-thread-safety-constructor IIRC. So it's probably not a long term solution.


It's important that all the issues getting hit be reported upstream at https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues .


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer

[toc] | [prev] | [next] | [standalone]

#1111971 — Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

On Wed, 3 Aug 2022 11:33:13 -0700 Max Bell <mbell@pobox.com> wrote:
> Why isn't the bug being fixed? That is obviously the correct solution.
So far, they argue that it's correct and only exposed bugs in all those
other packages. Which may even be correct. But without a clear
perspective of getting those fixed anytime soon, it's best to work
around in Debian.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web