sawfish + xinerama dropping / unmapping windows

[Janek Kozicki]

So I have just upgraded to three screens. I have configured them with
xinerama: 1600x1200,1920x1200,1600x1200. And now I have ran into this issue:

  http://mail.gnome.org/archives/sawfish-list/2007-December/msg00015.html

Previously I was using twinview, with its own implementation of
xinerama (the nvidia's one). And I never had such problem.

But now, with three screens I'm not using twinview anymore (because
it works only with two screens). And now I'm using /usr/lib/libXinerama.so
to merge all screens into single viewport. And the problem occurs. It
is relatively easy to reproduce. Here's what happens:

Just after logging into my session I open few standard windows:
email, few browsers, few terminals. Then while one of those is being
opened (so far it was when starting opera, but I can't tell now if it
is opera that is the cause of these all troubles - maybe it was when
starting firefox once?) : some several other random windows "disappear".

The "disappear" means:
 - I've seen that window on my screen, suddenly it's not there, I see
   the window disappearing while I look at it, then the background or
   windows beneath it get refreshed.
 - I've seen this window listed in the task list, suddenly it's not
   there.
 - I've seen this window in the pager, but now it's not there.
 - I've seen it in sawfish's window list, but suddenly it's not there.

Definitely the window gets unmapped.

The process is not killed. 'ps auxw' shows that the process is
running and doing fine.

`xwininfo -root -tree` shows that this window indeed exists.

sawfish-client (managed-windows) doesn't list this window.


We know that this problem doesn't occur with nvidia's propertiary
xinerama implementation, but only with /usr/lib/libXinerama.so

Did anybody tackle this issue, or we stopped at the point that was
last discussed in december 2007? (see the thread linked on top of
this email).

Tell me how to proceed with debugging.

I can run sawfish in valgrind (will try doing so). I'm not sure if
I could get libXinerama to run inside valgrind.

I never tried to produce xtrace, I Don't know how.

Other hints?

best regards
--
Janek Kozicki                                                         |

[Janek Kozicki]

Janek Kozicki said:     (by the date of Thu, 22 Oct 2009 22:14:32 +0200)

> Tell me how to proceed with debugging.
>
> I can run sawfish in valgrind (will try doing so). I'm not sure if
> I could get libXinerama to run inside valgrind.


I tried with valgrind: no errors whatsoever. sawfish is totally
clean, and there is no undefined behaviour. Here's what I get in valgrind:
(the text after # are my comments).


==5328== Memcheck, a memory error detector
==5328== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5328== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==5328== Command: /usr/bin/sawfish
==5328==
*** File error: No such file or directory, sawmill-defaults
*** Unbound variable: edge
(You're accessing an undefined variable or function `edge')
   # some ,,standard'' sawfish error, I always have it.

PID: 5337
sawfish-pager is running, stopping: 5337
   # my script to toggle on/off the pager is very talkative

Xlib:  extension "RANDR" missing on display ":0.0".
   # I just started firefox and several random windows have just disappeared.
   # this time it was:
   # - the root window with background image (so now the background is plain gray),
   # - claws-mail
   # - couple of xterms
   # rox-panel
   # This RANDR error is coming from very talkative firefox. I have no RANDR with xinerama

warning: failed to allocate a window
warning: failed to allocate a window
warning: failed to allocate a window
   # I tried renaming some files with rox ;)
   # next I quit sawfish

==5328==
==5328== HEAP SUMMARY:
==5328==     in use at exit: 3,345,976 bytes in 10,671 blocks
==5328==   total heap usage: 105,672 allocs, 95,001 frees, 15,397,129 bytes allocated
==5328==
==5328== LEAK SUMMARY:
==5328==    definitely lost: 5,908 bytes in 68 blocks
==5328==    indirectly lost: 7,504 bytes in 237 blocks
==5328==      possibly lost: 280,647 bytes in 2,737 blocks
==5328==    still reachable: 3,051,917 bytes in 7,629 blocks
==5328==         suppressed: 0 bytes in 0 blocks
==5328== Rerun with --leak-check=full to see details of leaked memory
==5328==
==5328== For counts of detected and suppressed errors, rerun with: -v
==5328== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 152
from 50)


Do you have some other hints about what to check?

--
Janek Kozicki                                                         |

[Janek Kozicki]

I'm slowly trying to figure this out. The bug is very annoying,
occurs virtually always. Not rarely. Impossible to open stuff,
because it disappears. :)

I added single line in src/windows.c remove_window() (see below for
full function code):

   fprintf(stderr,"deleting window, is it destroyed? - %d \n",(int)(destroyed));


And I see a very simple pattern of those messages:

 - when a window is unmapped legally (when it *should* be unmapped),
   because I simply closed something I get this message twice:

     deleting window, is it destroyed? - 1
     deleting window, is it destroyed? - 0

   For each single window close operation: two messages.

 - when a window is unmapped, when it shouldn't be, I get only ONE
   message:

     deleting window, is it destroyed? - 1


So - we have something to start with. Now I'm trying to figure out,
what to do next.

=================

Full function code in src/windows.c:

void
remove_window (Lisp_Window *w, bool destroyed, bool from_error)
{
    DB(("remove_window (%s, %s)\n",
        rep_STR(w->name), destroyed ? "destroyed" : "not-destroyed"));

fprintf(stderr,"deleting window, is it destroyed? - %d \n",(int)(destroyed));

    if (w->id != 0)
    {
        if (!destroyed && !from_error)
        {
            grab_window_events (w, FALSE);
            remove_window_frame (w);

            /* Restore original border width of the client */
            XSetWindowBorderWidth (dpy, w->id, w->attr.border_width);
        }

        if (!from_error)
            destroy_window_frame (w, FALSE);

        if (!WINDOW_IS_GONE_P (w))
            remove_from_stacking_list (w);

        if (!from_error)
            focus_off_window (w);

        w->id = 0;
        pending_destroys++;

        /* gc will do the rest... */
    }
    else if (w->frame != 0 && !from_error)
        destroy_window_frame (w, FALSE);
}



--
Janek Kozicki                                                         |

[Janek Kozicki]

I tracked all places where remove_window is called. The offending
call is at display.c:88

--
Janek Kozicki                                                         |

[Janek Kozicki]

Got it. I'm writing a patch page on wiki.

one of XErrorEvents handled in display.c:88 wasn't an error in fact,
it was an X_ConfigureWindow request.

--
Janek Kozicki                                                         |

[Janek Kozicki]

there you go:

http://sawfish.wikia.com/wiki/Xinerama_and_X_ConfigureWindow_fix

--
Janek Kozicki                                                         |

[Teika Kazura]

Chris, you commited the patch in
------------------------------------------------------------------------
commit 4c1aa73f9e1662ae7f76d2abb12b1eb272d5f416
Author: Christopher Roy Bratusek <chris@...>
Date:   Sat Oct 24 23:26:43 2009 +0200

    added debian packaging scripts based on the official ones
------------------------------------------------------------------------
but was it by mistake? Apparently what the log tells was meant, and
the Janek's patch was mixed.

What should we do? I think it's worth logging what is fixed for this
case, so git-revert? Is it excessive?

Thanks a lot Janek for your efforts. Sorry I can't help on this.
Teika (Teika kazura)

[Janek Kozicki]

Janek Kozicki said:     (by the date of Fri, 23 Oct 2009 22:11:55 +0200)

Guys, have you seen the latest comment at:

> http://sawfish.wikia.com/wiki/Xinerama_and_X_ConfigureWindow_fix

I guess that he is right. But I don't know what other codes ne have
to ignore (to avoid closing a window, if there is nothing wrong with
it). Can you  check this?


Chris you said that firefox sometimes disappears for you? Maybe you
can try printing the code numbers, using code that I pasted at the
start of this wikipage (those printfs()) and see what code numbers do
you have, before the window gets closed?

But maybe others know xlib a bit too, and can hint at what codes to
ignore.... Or somebody can check at source code of other window managers.

--
Janek Kozicki                                                         |

[Flashrider]

Am Dienstag, den 27.10.2009, 17:34 +0900 schrieb Teika Kazura:

> Chris, you commited the patch in
> ------------------------------------------------------------------------
> commit 4c1aa73f9e1662ae7f76d2abb12b1eb272d5f416
> Author: Christopher Roy Bratusek <chris@...>
> Date:   Sat Oct 24 23:26:43 2009 +0200
>
>     added debian packaging scripts based on the official ones
> ------------------------------------------------------------------------
> but was it by mistake? Apparently what the log tells was meant, and
> the Janek's patch was mixed.

Oops. I'll revert it now. I just wanted to commit the debian packaging
scripts ...

> What should we do? I think it's worth logging what is fixed for this
> case, so git-revert? Is it excessive?
>
> Thanks a lot Janek for your efforts. Sorry I can't help on this.
> Teika (Teika kazura)
>

Chris

[GSR - FR]

Hi,
janek_listy@... (2009-10-27 at 0958.01 +0100):
> > http://sawfish.wikia.com/wiki/Xinerama_and_X_ConfigureWindow_fix

For the record, Xinerama is being replaced by XRandR.

GSR
 

[Timo Korvola-2]

On Tuesday 27 October 2009 10:58:01 Janek Kozicki wrote:
> Guys, have you seen the latest comment at:
> http://sawfish.wikia.com/wiki/Xinerama_and_X_ConfigureWindow_fix

According to the X protocol manual, it is the failing resource id that
is returned.  Hence on BadWindow errors, ev->resourceid should not be a
valid window regardless of which request caused the error.  However, it
seems that sometimes ev->resourceid is a valid managed window, which is
then marked "gone" in the error_handler.  It is a mystery why this
happens.  Perhaps a bug in Xinerama if it only occurs when it is used?

Note that error_handler does not unmap the window.  X error handlers
must not interact with the X server.  I don't know where the window gets
unmapped.

> Chris you said that firefox sometimes disappears for you? Maybe you
> can try printing the code numbers,

It might also be useful to check whether ev->resourceid is equal to
w->id or w->frame.

> Or somebody can check at source code of other window managers.

Neither TWM nor FVWM use the error handler to detect missing windows
like Sawfish does.  Does anyone know of another window manager that uses
the same technique?

--
        Timo Korvola <URL:http://www.iki.fi/tkorvola>