#2314 Panic in [wm stackorder]

obsolete: 8.6b1
open
5
2009-04-04
2007-09-07
Joe English
No

Reported on the Tcl'ers chat (GPS and stever both replicated):

Running the Tk test suite under the Whim window manager causes a panic in [wm stackorder]

Problem narrowed down to test wm-stackorder-5.2:

++++ wm-stackorder-4.4 PASSED
++++ wm-stackorder-5.1 PASSED
num matched toplevel windows does not equal num children
/bin/sh: line 1: 20192 Aborted

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Stack backtrace here: http://paste.tclers.tk/377

    From which you can see (window_ptr - windows) == 1, table.numEntries == 2, which triggers the panic.

     
  • Joe English

    Joe English - 2007-09-17

    Logged In: YES
    user_id=68433
    Originator: YES

    More information:

    [wm stackorder] is computed by calling XQueryTree() on the "vroot" window, and trying to match each child of the "vroot" against the "reparent" window of all Tk toplevels.

    The "vroot" is either the RootWindow of the display, or the value of the __SWM_ROOT or __WM_ROOT root window property if present. The "reparent" window of a Tk toplevel is the ancestor of the client window which is a child of the "vroot", if it exists; otherwise it is the parent of the client window (where "client window" is as per the ICCCM). Both of these are computed in function "ReparentEvent", called whenever the client window gets a ReparentNotify.

    [wm stackorder] assumes that the "reparent" window of all mapped toplevels on the same display are children of a common "vroot", and panics if this is not the case.

    There are a number of ways in which this can go wrong:

    (1) There might not be a single virtual root (the EWMH and ICCCM allow for multiple virtual roots);
    (2) The virtual root might not be identified by __SWM_ROOT or __WM_ROOT (this appears to be an older, informal convention used -- presumably -- by Tom LaStrange's "swm"; the EWMH specifies that virtual roots are listed in _NET_VIRTUAL_ROOTS root window property);
    (3) override-redirect windows will not be descendants of any "vroot" if one is present;
    (4) Possible race conditions and other things I'm not clever enough to think of.

    #3 appears to be the cause of the panic in this particular case: wm-stackorder-5.2 creates two toplevels, one override-redirect and the other one not, then tests [wm stackorder]. The Whim window manager uses virtual roots (it uses multiple virtual roots, actually, although that does not appear to be relevant in this instance.)

     
  • Don Porter

    Don Porter - 2007-10-25

    Logged In: YES
    user_id=80530
    Originator: NO

    status?

     
  • Don Porter

    Don Porter - 2007-12-03

    Logged In: YES
    user_id=80530
    Originator: NO

    should this bug block 8.5.0 ?

     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    If you can get anyone's effort, yes. Block for this. (The fact that overrideredirect windows might also cause problems is a key factor my opinion.)

     
  • Nobody/Anonymous

    Logged In: NO

    Probably should not block 8.5.0. It only affects applications that use [wm stackorder] (of which there are very few) running under window managers that use multiple VROOTs (which is very uncommon -- Whim is the only one I've found so far; Enlightenment might also but I can't confirm).

     
  • Don Porter

    Don Porter - 2007-12-04
    • priority: 9 --> 8
     
  • Joe English

    Joe English - 2009-03-12

    Reported on the chat:

    (14:04:05) <saedelaere> i have a weird problem a user reported to me. i'am using this to dock my app into the tray http://wiki.tcl.tk/5972
    (14:04:55) <saedelaere> now when the user hits the icon in the system tray the application and the icon disappears.
    (14:05:27) <saedelaere> and he sees this message in his xsession-errors
    (14:05:28) <saedelaere> num matched toplevel windows does not equal num children
    (14:06:00) <saedelaere> he uses tcl 8.5.5 and kde 4.1.3
    (14:06:54) <saedelaere> i don't have this problem on kde 3.5.10 and tcl 8.5.2. I also checked with Ubuntu 8.04 and 8.10 (gnome) also no problem.
    (1:07:13) <saedelaere> the command causing this problem seems to be
    (14:07:14) <saedelaere> [wm stackorder .]
    (14:08:05) <saedelaere> i'am using this command to get all toplevels and then
    (14:08:05) <saedelaere> [wm withdraw] all of them, but the mentioned command kills the application.
    (14:09:58) <saedelaere> in normal conditions the [wm stackorder] command seems to work for him. now the question is, is this a bug in tk 8.5.5 or is tktray not usable with this version. i don't think it is a kde4 problem, because with kubuntu 8.10 and kde 4.1.4 everything works just fine.

     
  • Joe English

    Joe English - 2009-03-13
    • priority: 8 --> 9
     
  • Schelte Bron

    Schelte Bron - 2009-03-31

    I have received a bug report from a user reporting the same problem.

    I was able to reproduce the problem on a SuSE 11.1 system with both KDE3 and KDE4 installed. The program (using tktray) panics in [wm stackorder .] when using KDE 4.2.1 but it runs fine with KDE 3.5.10.

    Tcl version 8.5.5.

     
  • Donal K. Fellows

    • milestone: --> 874762
     
  • Donal K. Fellows

    Could this be the cause of the problem: overrideredirect windows are really direct children of the *real* root window, not any virtual root.

    In any case, shouldn't panic here. Bad assumption.

     
  • Joe English

    Joe English - 2009-04-03

    Cause of the problem is as outlined in earlier message [2007-09-17], and yes, the proximate cause of the problem is that override-redirect windows are not children of the "vroot".

    The deeper cause of the problem is that [wm stackorder] makes assumptions that are not justified by the ICCCM or EWMH. (In fact, everything in tkUnixWm.c that looks at the "reparent" window is highly suspect -- the "reparent" window is really a meaningless thing to be looking at.)

    I don't know how to implement [wm stackorder] correctly. In fact I'm not at all sure that it *can* be implemented correctly. In any event, Panic()ing when the assumptions are violated is obviously not acceptable.

     
  • Joe English

    Joe English - 2009-04-03
    • priority: 9 --> 5
     
  • Joe English

    Joe English - 2009-04-03

    "Fixed" in CVS (unix/tkUnixWm.c r1.70 ->r1.71).

    Patch replaces Tcl_Panic() calls that are prone to failure with /*ASSERT:*/ comments (which are still prone to failure). [wm stackorder] is still prone to giving "wrong" results in the presence of virtual roots, but it will no longer panic.

     
  • Joe English

    Joe English - 2009-04-03

    Addendum: left two Tcl_Panic() calls in, namely the ones that trigger on (C) programmer error. Those are safe and useful.

    The removed Panic() calls all triggered when the WM doesn't behave as expected, which is not safe. (Even if the underlying assumptions were correct -- which they're not -- it's still not a good idea to panic; Tk should not shoot itself in the foot when the WM misbehaves.)

     
  • Joe English

    Joe English - 2009-04-04

    tk-dont-panic-patch backported to core-8-5-branch.

     
  • Joe English

    Joe English - 2009-04-04
    • milestone: 874762 --> obsolete: 8.6b1
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks