xmonad/xmonad

un-trapped `getWindowAttributes` fail crashes xmonad, possibly after failed window drag

geekosaur opened this issue · 7 comments

Problem Description

I had a dialog window that was too large to fit on the screen, and attempted to drag it to see the rest of the window; nothing happened. I then pressed to clear the window (default button action), and xmonad crashed with

xmonad-x86_64-linux: user error (Error in function getWindowAttributes)

(The ones that are caught don't include an executable name; they just print the exception as is.)

Steps to Reproduce

  1. Create a dialog / floated window which is larger than the screen
  2. Attempt to mod-button1 drag it
  • This is not failing for me in a bare xmonad, at least if the window is initially in bounds but I resize it out of bounds.
  • It is possible that this issue relates to XMonad.Hooks.Place, since that is what is resizing the dialog in my config.
  1. Close the window by some means other than via xmonad (i.e. not mod-shift-c)

Configuration File

Please include the smallest full configuration file that reproduces
the problem you are experiencing:

module Main (main) where

import XMonad
import XMonad.Hooks.ManageHelpers
import XMonad.Hooks.Place

main :: IO ()
main = xmonad def {
                manageHook = isDialog --> placeHook (inBounds (smart (0.5, 0.5)))
              }

Checklist

  • I've read CONTRIBUTING.md

  • I tested my configuration

    • With xmonad version 0.17.2.9 (commit eeac754 if using git)
    • With xmonad-contrib version 0.17.1.9 (commit 673de11c if using git)

My suspicion is that the drag was never completed and crashes when the window goes away. Do we check for this?

(The ones that are caught don't include an executable name; they just print the exception as is.)

I don't think that this is true. I can reproduce the spam of

user error (Error in function getWindowAttributes)

once the window goes away, but can't reproduce the crash at all. Indeed, making the following change

diff --git a/src/XMonad/Core.hs b/src/XMonad/Core.hs
index 631f847..0c6b5a5 100644
--- a/src/XMonad/Core.hs
+++ b/src/XMonad/Core.hs
@@ -196,7 +196,7 @@ catchX job errcase = do
     c <- ask
     (a, s') <- io $ runX c st job `E.catch` \e -> case fromException e of
                         Just (_ :: ExitCode) -> throw e
-                        _ -> do hPrint stderr e; runX c st errcase
+                        _ -> do hPrint stderr ("CAUGHT: " <> show e); runX c st errcase
     put s'
     return a

and going over the recipe again correctly prints

"CAUGHT: user error (Error in function getWindowAttributes)"

to stderr. These exceptions seem to be correctly caught inside of some userCode call.

Isn't that what I said about the usual ones? The point is that somewhere there's an uncaught one. I'll probably need to do a profiling build and a reproducer to spot the one that leaked.

Oh sorry, my brain must have s/executable name/function name/'d

Can you consistently reproduce this with the above setup? If yes, and you think it's really the dragging, perhaps try adding an explicit userCodeDef to the dragging code

diff --git a/src/XMonad/Operations.hs b/src/XMonad/Operations.hs
index 9101cc0..7ff44df 100644
--- a/src/XMonad/Operations.hs
+++ b/src/XMonad/Operations.hs
@@ -783,9 +783,7 @@ mouseDragCursor cursorGlyph f done = do
         withDisplay $ io . flip ungrabPointer currentTime
         modify $ \s -> s { dragging = Nothing }
         done
-    motion x y = do z <- f x y
-                    clearEvents pointerMotionMask
-                    return z
+    motion x y = userCodeDef () (f x y) >>= \z -> z <$ clearEvents pointerMotionMask
 
 -- | Drag the window under the cursor with the mouse while it is dragged.
 mouseMoveWindow :: Window -> X ()

I can't reproduce it now for some reason: I get the mis-sized window, but it drags for both move and resize fine. I wonder what went wrong the first time.

Curiously, I arranged for a dialog to disappear on xmonad during a drag and can't reproduce even that way. (The original circumstances I am assuming are due to some weirdness in my setup that I can't reliably reproduce and seems to be tied to something completely unrelated, so I haven't bothered to report it.)

Closing for now.