xmonad's spawn function seems to launch applications only in about 50% of cases. Usually this seems to affect X applications. This bug seems to occur with ghc 7.6.3 but not with ghc 7.4.2_1. For both ghc versions I tested it with xmonad 0.11 install from ports or hackage and the error occurs only with ghc 7.6.3. There are a few workarounds, for example using the definition of spawn from xmonad 0.8 seems to solve this issue. dezzy from IRC suggested using spawn' s = spawn $ "exe=`" ++ s ++ "` && eval \"exec $exe\"" Another observation I made with the command spawn "date >> $HOME/bla; urxvt" is that the output for date is written to `bla' every time, while the terminal (urxvt) does not always start properly. Also ghc 7.6.3 and xmonad 0.11 on debian linux (sorry I have to use that at work) does not have similar issues. This caused us to believe there might be a bug in FreeBSD's ghc. I would suspect one could identify the problematic function by comparing the definition of spawn from xmonad 0.8 and xmonad 0.11. How-To-Repeat: Install ghc 7.6.3 from ports and xmonad 0.11 from ports or hackage. Then try opening a number of terminal windows (Mod-Shift-Enter) and see that a terminal is not always started after using that key combination.
Responsible Changed From-To: freebsd-ports-bugs->haskell Over to maintainer (via the GNATS Auto Assign Tool)
For your information, I have just updated lang/ghc to 7.8.3. I have been using it for a while with xmonad and I have not met this problem since then. Could you please verify this and get back to me with your results?
Hi, thank you for your response. I just tested it and I still have this problem with ghc 7.8.3. Personally, I have no idea how to diagnose this further.. truss came up empty or nothing that I found suspicious. I could post my poudriere config and access to the repo I am using if you thing it might help. But since I'm apparently the only person having that problem I don't mind if you close the bug. I'll just keep using the spawn code from xmonad 0.8. Best regards Dominik
You are not necessarily the only one who experiences this, but the one who actually reported it :-) The configuration I have been using with GHC 7.8.3 and xmonad 0.11 is a 2x2-core (Hyperthreaded) FreeBSD/i386 9.2-RELEASE. Perhaps you have a different system or architecture which is still affected by this "bug". So, could you please post a `uname -a` output? Regarding tracking the issue down: I would first study the functions that are responsible for the newer version of `spawn` in xmonad 0.11. They may reach down to certain standard library functions that are shipped with GHC. I will just keep this ticket open then -- I was just curious if the problem still persists.
I posted a workaround patch on the xmonad bugtracker: https://code.google.com/p/xmonad/issues/detail?id=576#c20 . So far it seems to alleviate the problem. It's not the exact same patch I've been using so my personal experiences are limited.
A commit references this bug: Author: pgj Date: Sun Feb 15 21:46:07 UTC 2015 New revision: 379052 URL: https://svnweb.freebsd.org/changeset/ports/379052 Log: - Add a (default) xmonad workaround for losing hotkeys in certain cases. For the details, please see the related bug report or issue #576 in the xmonad bug tracker [1]. [1] https://code.google.com/p/xmonad/issues/detail?id=576 PR: 181049 Submitted by: Dominik Ernst <de@dernst.org> Obtained from: FreeBSD Haskell MFH: 2015Q1 Changes: head/x11-wm/hs-xmonad/Makefile head/x11-wm/hs-xmonad/files/ head/x11-wm/hs-xmonad/files/nopatch-XMonad_Core.hs head/x11-wm/hs-xmonad-contrib/Makefile
A commit references this bug: Author: pgj Date: Mon Feb 16 22:04:24 UTC 2015 New revision: 379122 URL: https://svnweb.freebsd.org/changeset/ports/379122 Log: MFH: r379052 - Add a (default) xmonad workaround for losing hotkeys in certain cases. For the details, please see the related bug report or issue #576 in the xmonad bug tracker [1]. [1] https://code.google.com/p/xmonad/issues/detail?id=576 PR: 181049 Submitted by: Dominik Ernst <de@dernst.org> Approved by: portmgr (erwin) Obtained from: FreeBSD Haskell Changes: _U branches/2015Q1/ branches/2015Q1/x11-wm/hs-xmonad/Makefile branches/2015Q1/x11-wm/hs-xmonad/files/ branches/2015Q1/x11-wm/hs-xmonad-contrib/Makefile
The fix has been already committed, so I am closing this PR.
Please do not close tickets without consulting the maintainer. I am re-opening the ticket as it is not yet fixed, only a workaround has been committed.
Note that an update to GHC 7.10.2 has been committed to the ports tree. It also includes a patch that is to address the issue about configuring the available timers properly, which may help with this problem as well. Please test xmonad with it (without the fix included to the port) and get back with the results.
9.2 RELEASE is EOL. We hab ghc version 8.0.2. I think this is overcome by events.
Judging from comment 6 of https://code.google.com/archive/p/xmonad/issues/576 my fix ( https://phabricator.haskell.org/D831 )was indeed a proper one. The reporter said the child was getting SIGALRM: > 1) fork() 2) child process executing 3) poll(); recvmsg; setitimer(); poll(); SIGALRM This is exactly the same problem I was fixing with my patch. So, I believe the bug can be marked resolved.