Bug 181049 - lang/ghc: possible regression
Summary: lang/ghc: possible regression
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-haskell (Nobody)
Depends on:
Reported: 2013-08-05 12:40 UTC by de
Modified: 2018-01-16 09:11 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description de 2013-08-05 12:40:00 UTC
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.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2013-08-05 12:40:08 UTC
Responsible Changed
From-To: freebsd-ports-bugs->haskell

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Gabor Pali freebsd_committer freebsd_triage 2014-08-10 23:09:28 UTC
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?
Comment 3 de 2014-08-14 17:25:14 UTC

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
Comment 4 Gabor Pali freebsd_committer freebsd_triage 2014-08-14 19:43:07 UTC
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.
Comment 5 de 2015-01-21 07:46:57 UTC
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.
Comment 6 commit-hook freebsd_committer freebsd_triage 2015-02-15 21:46:48 UTC
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

  - 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

Comment 7 commit-hook freebsd_committer freebsd_triage 2015-02-16 22:04:29 UTC
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

  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

_U  branches/2015Q1/
Comment 8 Bartek Rutkowski freebsd_committer freebsd_triage 2015-03-29 11:22:17 UTC
The fix has been already committed, so I am closing this PR.
Comment 9 Gabor Pali freebsd_committer freebsd_triage 2015-03-29 11:28:13 UTC
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.
Comment 10 Gabor Pali freebsd_committer freebsd_triage 2015-08-21 11:06:08 UTC
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.
Comment 11 Walter Schwarzenfeld freebsd_triage 2018-01-12 03:44:24 UTC
9.2 RELEASE is EOL. We hab ghc version 8.0.2. I think this is overcome by events.
Comment 12 Gleb Popov freebsd_committer freebsd_triage 2018-01-16 08:57:44 UTC
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.