10564 – xfwm4 --replace fails when built with --enable-debug

xfwm4 --replace fails when built with --enable-debug

Status:

RESOLVED: FIXED

Priority:
Medium

Severity:
normal

Product:
Xfwm4

Component:

General

Comments

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.

BadWindow:
1. add_win, compositor.c:2100, ... compositorHandleReparentNotify
2. add_win (ditto), ... compositorHandleCreateNotify
3. myDisplayGetRootFromWindow, display.c:601, ... handleUnmapNotify
BadDamage:
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:

void
myDisplayGrabServer (DisplayInfo *display)
{
    g_return_if_fail (display);

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

void
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)");
}
#endif

Comment 7 Olivier Fourdan editbugs

2015-02-03 10:24:07 CET

xfwm4 now logs to a file. closing.

Comments

Bug #10564

People

Version

Attachments

Additional information