! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfwm4 --replace fails when built with --enable-debug


Description Andrzej editbugs 2013-12-23 01:34:19 CET
xfwm4 built with --enable-debug

running xfwm4 --replace from an xterm causes the display to freeze after painting root window. Killing xfwm4 and restarting it from console does not help.

A commit that seems (not sure!) to trigger this behavior is:
6836083 Repaint the screen when background changes.

Possibly related: I am also seeing a number of BadWindow and BadDamage errors, even in earlier versions.

1. add_win, compositor.c:2100, ... compositorHandleReparentNotify
2. add_win (ditto), ... compositorHandleCreateNotify
3. myDisplayGetRootFromWindow, display.c:601, ... handleUnmapNotify
4. free_win_data, compositor.c:798, ... compositorHandleDestroyNotify

The problem goes away after rebuilding xfwm4 with --disable-debug.
Comment 1 Alistair Buxton 2014-01-12 21:18:28 CET
This happens because there are some debug statements that fire while xfwm has an exclusive lock on the server. The debug statements write to the terminal which draws on the screen. But it can't because the server is grabbed. So this causes a deadlock. The offending debug statements are inside display.c in the server grab code:

myDisplayGrabServer (DisplayInfo *display)
    g_return_if_fail (display);

    DBG ("entering myDisplayGrabServer");
    if (display->xgrabcount == 0)
        DBG ("grabbing server");
        XGrabServer (display->dpy);
    DBG ("grabs : %i", display->xgrabcount);

myDisplayUngrabServer (DisplayInfo *display)
    g_return_if_fail (display);

    DBG ("entering myDisplayUngrabServer");
    display->xgrabcount = display->xgrabcount - 1;
    if (display->xgrabcount < 0)       /* should never happen */
        display->xgrabcount = 0;
    if (display->xgrabcount == 0)
        DBG ("ungrabbing server");
        XUngrabServer (display->dpy);
        XFlush (display->dpy);
    DBG ("grabs : %i", display->xgrabcount);

To avoid the problem either remove these specific debug statements or redirect the output to a file when running in debug mode.
Comment 2 Nick Schermer editbugs 2014-07-28 18:44:29 CEST
Only commenting out the DBG statements is pointless, because there are others in the functions calling the grab.
Comment 3 Nick Schermer editbugs 2014-07-28 19:05:24 CEST
Btw, the bug was there before 6836083, I always manually redirect to a terminal with &>~/xfwm4log when running from a terminal.
Comment 4 Alistair Buxton 2014-08-05 02:43:29 CEST
I tested commenting only those DBG statements and it prevented the freeze... I don't know why, but it does work.
Comment 5 Nick Schermer editbugs 2014-08-05 09:50:59 CEST
Weird, pretty sure there are other DBG messages between the grab and ungrab. Anyway, feel tree to comment them out in the code with a note to this bug.
Comment 6 Alistair Buxton 2014-08-05 17:38:02 CEST
Perhaps the other DBG statements are in conditional code paths, so they don't always trigger right away. I didn't test very much.

Maybe a better approach would be to put something in the startup like:

#ifdef DEBUG
if (stderr is a tty) {
    DBG("WARNING: Compiled with debug and output is going to a console. This may cause a deadlock unless you redirect output to a file (xfwm4 2>&1 > log.txt)");
Comment 7 Olivier Fourdan editbugs 2015-02-03 10:24:07 CET
xfwm4 now logs to a file. closing.

Bug #10564

Reported by:
Reported on: 2013-12-23
Last modified on: 2015-02-03


Olivier Fourdan
CC List:
2 users




Additional information