October 2011 - Glasgow-haskell-users

Re: Is this a concurrency bug in base?
by Jean-Marie Gaillourdet 09 Oct '11

09 Oct '11

Hi, the Eq instance of TypeRep shows the same non-deterministic behavior: import Control.Concurrent import Control.Exception import Control.Monad import Data.Typeable main :: IO () main = do { fin1 <- newEmptyMVar ; fin2 <- newEmptyMVar ; forkIO $ return (typeOf ()) >>= evaluate >>= putMVar fin1 ; forkIO $ return (typeOf ()) >>= evaluate >>= putMVar fin2 ; t1 <- takeMVar fin1 ; t2 <- takeMVar fin2 ; when (t1 /= t2) $ putStrLn $ "typeOf " ++ show t1 ++ " /= typeOf " ++ show t2 } $ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs <snip> $ while true ; do ./TypeRepEq +RTS -N ; done typeOf () /= typeOf () typeOf () /= typeOf () ^C^C $ On 09.10.2011, at 16:04, David Brown wrote: > The program below will occasionally print "1 /= 0" or "0 /= 1" on > x86_64 linux with the Debian testing 7.0.4 ghc. > > $ ghc bug -rtsopts -threaded > $ while true; do ./bug +RTS -N; done > >> module Main where >> import Control.Monad >> import Control.Concurrent >> import Data.Typeable >> main :: IO () >> main = do >> fin1 <- newEmptyMVar >> fin2 <- newEmptyMVar >> forkIO $ child fin1 >> forkIO $ child fin2 >> a <- takeMVar fin1 >> b <- takeMVar fin2 >> when (a /= b) $ >> putStrLn $ show a ++ " /= " ++ show b >> child :: MVar Int -> IO () >> child var = do >> key <- typeRepKey (typeOf ()) >> putMVar var key Thanks again for reproducing it. Jean

1 0

GHC, Clang & XCode 4.2
by austin seipp 07 Oct '11

07 Oct '11

There has been recent discussion on the Homebrew bug tracker concerning the upcoming XCode 4.2 release by Apple, which has apparently just gone GM (meaning they're going to make a real release on the app store Real Soon Now.) The primary concern is that XCode will no longer ship GCC 4.2 at all, it seems. XCode 4.0 & 4.1 merely set 'llvm-gcc' as the default compiler, and GHC's `configure` script was adjusted to find the `gcc-4.2` binary. If you have old XCode's installed, then you may have the binaries laying around, but I doubt they'll be on your $PATH, and anybody doing a fresh install is SOL. It seems Clang 3.0 will now be the default compiler, with llvm-gcc as a deprecated option, probably removed in XCode 4.3. It doesn't matter really, because both of them do not work with GHC, because of its use of either A) Global register variables of any kind, or B) the __thread storage modifier. David Peixotto did some work on this not too long ago as the issue of compiling with Clang was raised. His branches include changes which make the 'gct' variable use pthread_getspecific rather than __thread for TLS and then as an optimization use inline ASM to grab the value out of the variable, with an impact of about 9% it seems, but that's on nofib and I don't know if it was -threaded. He also included a version which passes the 'gct' around as a parameter to all GCC functions which is a bit uglier but may give some better performance I guess. (The discussion is from here IIRC.) I suppose the real perf killer here is probably -threaded code. https://github.com/dmpots/ghc Was there ever any decision on which route to take for this issue? The parameter passing solution looks quite uglier IMO but it may be necessary for performance. I'm just posting this here as a reminder as this is probably going to become a problem pretty quickly for anybody who uses Lion or modern XCode and also likes using GHC, so it should probably be sorted out. :) I'm still on SL using XCode 4 so it's not an issue for me, but it will be for any future Mac endeavors. Hopefully they get support for __thread or something equivalent soon, because nobody likes performance hits, but it doesn't seem like we have a choice. -- Regards, Austin

4 3

mkTopLevEnv: not interpreted main:Main
by Chris Smith 07 Oct '11

07 Oct '11

So I'm trying to fix a bug in a web application that's using the GHC API with GHC 7.2. If it helps, the application is gloss-web, source code at https://github.com/cdsmith/gloss-web and the relevant module is src/Source.hs. The error I'm getting is <no location info>: mkTopLevEnv: not interpreted main:MyModule I get this occasionally when two pieces of source code happen to get compiled at approximately the same time, but most of the time everything works fine. The module name there is whichever one I've defined in the source code I'm compiling. It's correct that the module is not interpreted; I'm specifying options hscTarget = HscAsm ghcLink = LinkInMemory But it's unclear to me why GHC occasionally decides to require that it be interpreted and complain, when compiling the code works fine in any other circumstance. Anyone else seen anything like this, or know what the cause is? A few notes: 1. It doesn't appear to be a straight-forward reentrancy issue, as wrapping uses of the GHC API with an MVar lock doesn't affect it at all. However, it definitely *is* correlated with multiple compiles at approximately the same time. Very odd there. 2. On a whim, I tried adding a performGC before and after each use of the compiler to try to isolate the uses of the GHC API more completely. Oddly enough, a performGC before the compile makes the problem much WORSE. I found that interesting; maybe it's a hint. 3. If you want to build my code and reproduce it, the easiest way is to comment out line 110 (keepAlive cmap digest 30) of src/Source.hs. Doing so will break the bit that caches recently compiled source code, making it much easier to actually call the GHC API several times in rapid succession just by rapidly clicking the Run button in the web app. If there's anything I can do to get more information, I'm happy to do so as well. I'm not terribly familiar with the flags or options for GHC, as I've never done this before. -- Chris Smith

4 11

REQ: add a non-closing version of handleToFd
by Volker Wysk 06 Oct '11

06 Oct '11

Hello The function to extract a file descriptor from a handle, handleToFd, closes the handle as a side effect. This appears to be necessary in the general case, otherwise the implementers wouldn't have made it this way. But there are cases in which it isn't necessary to close the handle. For instance, this little function needs to extract the file descriptor, but there is no need to close, or change, the handle. isatty :: Handle -- ^ Handle to check -> IO Bool -- ^ Whether the handle is connected to a terminal isatty h = do fd <- handleToFd_noclose h isterm <- {# call isatty as hssh_c_isatty #} -- this is c2hs ((fromIntegral fd) :: CInt) return (isterm /= (0::CInt)) handleToFd_noclose :: Handle -> IO Fd -- to be implemented The isatty above can't be implemented with things the way they are. To me, this is a serious drawback. The cases, in which the handle needs to be closed, should be identified, and documented. Then, a version of handleToFd, which doesn't close the handle can be implemented. Cheers Volker

4 3

Mysterious function timer_settime
by Volker Wysk 06 Oct '11

06 Oct '11

Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal build Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... (...) Registering hsshellscript-3.0.0... ~/src/hsshellscript-3.0.0 $ cabal haddock Running Haddock for hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... (...) Documentation created: dist/doc/html/hsshellscript/index.html ~/src/hsshellscript-3.0.0 $ cabal install Resolving dependencies... Configuring hsshellscript-3.0.0... Preprocessing library hsshellscript-3.0.0... Building hsshellscript-3.0.0... Registering hsshellscript-3.0.0... Installing library in /home/v/.cabal/lib/hsshellscript-3.0.0/ghc-7.0.4 Registering hsshellscript-3.0.0... I've made a fine little test program src/test.hs: import HsShellScript main = (outm "3\n1\n2\n") -|- exec "/usr/bin/sort" ["-n"] But this doesn't work. It generates a mysterious error message: ~/src/hsshellscript-3.0.0 $ src/test test: <stderr>: hPutStr: illegal operation (handle is closed) test: timer_settime: Invalid argument "timer_settime" occurs only in the generated test binary. It doesn't occur anywhere in the library or in "/usr/bin/sort": ~/src/hsshellscript-3.0.0 $ find -type f -print0|xargs -0 egrep timer_settime Übereinstimmungen in Binärdatei ./src/test. ~/src/hsshellscript-3.0.0 $ egrep timer_settime /usr/bin/sort (no output) It looks like GHC has introduced this mysterous call of timer_settime. What does that mean? Thanks for any help, Volker W.

2 3

Re: [Pkg-haskell-maintainers] libffi soname change upcoming
by Joachim Breitner 04 Oct '11

04 Oct '11

Hi, Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose: > > The question that has to be answered first is: Assume the libraries do > > not depend on libffi themselves, and only ghc does. Now you update > > libffi and ghc gets rebuilds, what will happen: > > > > A) The haskell ABIs stay the same, the existing library packages can > > still be used. Great. > > > > B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries, > > but oh well, not bad thanks to BD-Uninstallable-support in wanna-build > > and autosigning. > > > > C) The haskell ABIs do not change, but the old library builds are > > broken nevertheless. Big mess. Hard to recover from, because builds are > > not ordered automatically any more. Needs lots of NMUes and Dep-Waits. > > sorry, I don't get the `C' case. why should these be broken by a libffi or > libgmp change? Maybe it’s an unrealistic example, but I could imagine that ghc some data type (size) defined by libffi is used when generating code for a haskell library under the assumption that it has the same structure/size in the run time system and/or other used haskell libraries. But instead of making blind guesses, maybe GHC upstream can enlighten us: Is it safe to build ghc and a Haskell library, then upgrade libffi to a new version (with soname bump), rebuild ghc, but use the previous library build? > > Removing the libffi dependencies from the haskell libraries makes C > > possible and only helps with A. So until someone investigates this, I’d > > rather err on the safe side, leave the dependencies in, and fix the > > issue by rebuilding all haskell libraries when you upload the new ffi > > soname to unstable. > > well, with binNMU orgies like this you'll pull in any new or tightened > dependencies for shared libraries. Not depending on these unused libraries > does avoid this. True. I agree that it would be nice and worthwhile to remove the libffi dependency from the libraries, but only if it is actually safe and scenario C is guaranteed not to happen. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 4

Getting the file descriptor from a handle, without closing it
by Volker Wysk 01 Oct '11

01 Oct '11

Hello! I need to get the file descriptors of some handles, but the handles should not be modified. They should not be closed by the operation. I guess, that the handle gets closed for a reason. But I'm using the revealed file descriptors in a way which should pose no problems for the integrity of the GHC library. In order to make a non-closing handleToFd function, I'm studying GHC's library source code. But there's a lot which I can't make much sense, because it uses non-standard language features (GHC extensions), which I'm not familiar with. I don't mean you to explain these GHC extensions to me. I just want to give an impression of the problems I encounter: 1. data FD = FD { fdFD :: {-# UNPACK #-} !CInt, fdIsNonBlocking :: {-# UNPACK #-} !Int } What is that exclamation mark? And that "{-# UNPACK #-}"? 2. handleToFd' :: Handle -> Handle__ -> IO (Handle__, Fd) handleToFd' h h_@Handle__{haType=_,..} = do case cast haDevice of -- ... haDevice should be a function. How could you cast it? 3. data Handle__ = forall dev enc_state dec_state . (IODevice dev, BufferedIO dev, Typeable dev) => Handle__ { -- ... } deriving Typeable What's that "forall" thing? 4. handleToFd' h h_@Handle__{haType=_,..} = do case cast haDevice of Nothing -> -- ... Just fd -> do -- ... return (Handle__{haType=ClosedHandle,..}, Fd (fromIntegral (FD.fdFD fd))) What's this ".." inside "Handle__{haType=ClosedHandle,..}"? If anyone can point out to me, how this non-blocking handleToFd function should be made, I would be grateful. Greetings Volker Wysk

2 2