Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xmonad crash if too many windows opened in BinarySpacePartition #753

Open
3 tasks done
geekosaur opened this issue Sep 7, 2022 · 3 comments
Open
3 tasks done

xmonad crash if too many windows opened in BinarySpacePartition #753

geekosaur opened this issue Sep 7, 2022 · 3 comments

Comments

@geekosaur
Copy link
Contributor

Problem Description

I suspect either a lazy division by zero forced in X.O.windows, or a zero-size window. (The binary regression into the upper left corner of the screen was amusing until xmonad crashed. My taskbar counted 30 windows when xmonad stopped updating the EWMH properties it uses, so it apparently got them all opened before crashing; see "reproduce" below.)

Steps to Reproduce

I ran for f in *; do display "$f"; done in a directory with 30 image files in it. Presumably opening 30 xterms would also work.

Configuration File

module Main (main) where

import XMonad
import XMonad.Layout.BinarySpacePartition

main :: IO ()
main = xmonad def { layoutHook = emptyBSP }

Checklist

  • I've read CONTRIBUTING.md

  • I tested my configuration

    • With xmonad version 0.17.1 (commit d0f12af if using git)
    • With xmonad-contrib version 0.17.1 (commit fd5970f if using git)

Note

I'm still trying to diagnose this better locally; I inadvertently tripped it last night before bed, and couldn't find any smoking guns in the session log this morning.

geekosaur added a commit to geekosaur/xmonad.hs that referenced this issue Sep 7, 2022
then work around a restart-xmonad issue after discovering
xmonad/xmonad-contrib#753
@slotThe
Copy link
Member

slotThe commented Sep 8, 2022

I can't reproduce this. I ran for i in {0..50}; do xterm & done with that given config but—while xmonad slowed down to a crawl, which is maybe a bug in itself—observed no crash

@geekosaur
Copy link
Contributor Author

geekosaur commented Oct 14, 2022

I'm wondering if it's the OOM killer. I reproduced it again with a smaller image viewer, but things actually worked for a while until I tried to focus a window and my swap suddenly filled up and xmonad died again. Which makes little sense to me because I don't see a reason for xmonad to have suddenly started using that much memory, unless I've perhaps somehow found a bug in the dbus binding. But that doesn't make much sense either.

Or maybe it needs EwmhDesktops to reproduce or something, but then I don't see why it would have worked for a while.

I may set up a VM to play with this in, so I don't OOM my system again.

@geekosaur
Copy link
Contributor Author

I have reproduced this exactly once so far, and still have nothing to show for it.

Slightly more common is that I now have a BSP layout with 8 windows in it, and occasionally when switching to it xmonad hangs for up to a minute. So I'm pretty sure something is wrong with BSP but I still have no idea what.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants