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
>
>
Reply to: