Re: [STUMP] Mixxx sends stump into crash loop

[Shawn Betts]

>  (B7291CDC) : 8 (FUNCALL #'#<#<CCL::STANDARD-KERNEL-METHOD 
> NO-APPLICABLE-METHOD (T)>> #<STANDARD-GENERIC-FUNCTION STUMPWM::WINDOW-GROUP 
> #x1515DC5E> NIL) 103
>  (B7291CFC) : 9 (WINDOW-SCREEN NIL) 39
>  (B7291D0C) : 10 (X-OF NIL STUMPWM::ONLY-TRANSIENTS) 39
>  (B7291D1C) : 11 (TRANSIENTS-OF NIL) 63
>  (B7291D2C) : 12 (SHADOWS-OF #S(TILE-WINDOW "Sound Device Busy" #x1406741)) 
> 423
>  (B7291D50) : 13 (MODALS-OF #S(TILE-WINDOW "mixxx" #x1406787)) 271
>  (B7291D70) : 14 (RAISE-MODALS-OF #S(TILE-WINDOW "mixxx" #x1406787)) 39

Looks like shadows-of borks trying to find the transient-for window of
the "Sound Device Busy" window. It looks like the problem is that
window-by-id doesn't find the window in its hash table and returns
NIL. It's unclear why that window wouldn't be in the hash table since
it's presumably the "mixxx" window. When stumpwm is notified of a new
window to manage, it adds the window to a hash table stored in the
global variable *xwin-to-window*. This makes it convenient for
functions to find the stumpwm structure that corresponds to the X
window ID. It's completely unnecessary and a nasty wart of a hack. The
same information could be found by searching the group window list of
each group in the xwin's screen as well as the screen's
withdrawn-windows list.

While it probably won't fix this bug (but it might), anyone brave
enough is welcome to rewrite window-by-id :). Regardless, the code
that is breaking, above, should probably be modified to be more
resilient in the face of a nonexistent transient-for window since a
non-compliant, buggy client could toss a bogus value in there and
bring down the wm, which would make us ALL look bad.

-Shawn