FS#18867 - [xmobar] 0.9.2-2 crashes when used with Midori
Attached to Project:
Community Packages
Opened by Randy Heydon (Tempel) - Sunday, 28 March 2010, 22:21 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 18 May 2010, 11:23 GMT
Opened by Randy Heydon (Tempel) - Sunday, 28 March 2010, 22:21 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 18 May 2010, 11:23 GMT
|
Details
Description:
With yesterday's package update (0.9.2-1 -> 0.9.2-2), xmobar fails in one of several interesting ways whenever the web browser Midori (version 0.2.4-1) is given focus. This has been observed when used with window manager Xmonad (config file xmonad.hs attached), but has not been tested within other window managers. This problem has not been observed in conjunction with any program besides Midori. This never occurred before yesterday's update. Sometimes, after focusing on Midori, xmobar will run satisfactorily for several minutes before locking up; sometimes this lock up occurs as soon as Midori is given focus. Either way, xmobar will have its output stuck at whatever it happened to be at that moment. Workspace, window title, system stats, and time (everything included in my attached .xmobarrc) stay exactly as they are. This is accompanied by absolutely no debugging output in the terminal. Other times, as soon as Midori is given focus, xmobar will crash entirely; where it once was, nothing is visible, its process ends, and a line is output to terminal saying "xmobar: Enum.toEnum{Word8}: tag (8234) is outside of bounds (0,255)", which is followed by "<file descriptor: 4>: hPutChar: resource vanished (Broken pipe)", appearing once each time the window title would change. I haven't figured out exactly what triggers one failure mode or the other. I have found that changing window focus to Midori within a single workspace (Mod-tab) will trigger an instant lock-up, but changing workspaces to land on Midori (Mod-<workspace #>) will trigger a crash. Restarting Xmonad (Mod-q) will fix xmobar regardless of failure mode, but restarting while focused on Midori will cause xmobar to crash immediately. I hope this has been informative, and I hope it's not too much of a pain to fix. I don't like the thought of switching back to Firefox. |
xmonad.hs
This task depends upon
Closed by Sergej Pupykin (sergej)
Tuesday, 18 May 2010, 11:23 GMT
Reason for closing: Fixed
Additional comments about closing: xmobar was updated to 0.11.1
Tuesday, 18 May 2010, 11:23 GMT
Reason for closing: Fixed
Additional comments about closing: xmobar was updated to 0.11.1
Temporary solution: run xmobar with without StdinReader but this is so ugly and not usable.
It's fixed in the latest darcs rev. However, if you don't want to use the development version (like me), you can disable uft8 for now:
# Contributor: Arch Haskell Team <arch-haskell@haskell.org>
# Package generated by cabal2arch 0.4
pkgname=xmobar
pkgver=0.9.2
pkgrel=2
pkgdesc="A Minimalistic Text Based Status Bar"
url="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmobar"
license=('custom:BSD3')
arch=('i686' 'x86_64')
makedepends=('ghc' 'haskell-x11>=1.3.0' 'haskell-stm' 'haskell-parsec' 'haskell-mtl')
depends=('gmp' 'libxinerama')
options=('strip')
source=(http://hackage.haskell.org/packages/archive/xmobar/$pkgver/xmobar-$pkgver.tar.gz)
md5sums=('1177eef9f032256ccf370239a0703eab')
build() {
cd $startdir/src/xmobar-$pkgver
runhaskell Setup configure --disable-optimization --prefix=/usr --constraint="base<4" --flags="-with_xft -with_utf8"|| return 1
runhaskell Setup build || return 1
runhaskell Setup copy --destdir=$startdir/pkg || return 1
install -D -m644 LICENSE $startdir/pkg/usr/share/licenses/$pkgname/LICENSE || return 1
}
The trick I found to work is forcing the IO handle to UTF8 mode, "hSetEncoding xmobar utf8" and using System.IO.hPutStrLn (not System.IO.UTF8 which is now deprecated). All of which is a bit weird.
Other stuff about 6.12.1 @ http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know-about-unicode-io-in-ghc-6-12-1/
hope it helps