May 2012 - Glasgow-haskell-users

Explicit calls to the garbage collector.
by Jurriaan Hage 08 May '12

08 May '12

LS. I have a very memory intensive application. It seems that the timing of my application depend very much on the precise setting of -H...M in the runtime system (-H2000M seems to work best, computation time becomes a third of what I get when I pass no -H option). I conjecture that this good behaviour is the result of gc happening at the right time. So I wondered: if I can one when is the right time, is it possible then to trigger GC explicitly from within the Haskell code? best, Jur

5 5

Weird behavior of the NonTermination exception
by Bas van Dijk 04 May '12

04 May '12

Hello, Before I turn the following into a ticket I want to ask if I miss something obvious: When I run the following program: ------------------------------------------------- import Prelude hiding (catch) import Control.Exception import Control.Concurrent main :: IO () main = do mv <- newEmptyMVar _ <- forkIO $ do catch action (\e -> putStrLn $ "I solved the Halting Problem: " ++ show (e :: SomeException)) putStrLn "putting MVar..." putMVar mv () putStrLn "putted MVar" takeMVar mv action :: IO () action = let x = x in x ------------------------------------------------- I get the output: $ ghc --make Loop.hs -o loop -O2 -fforce-recomp && ./loop [1 of 1] Compiling Main ( Loop.hs, Loop.o ) Linking loop ... loop: thread blocked indefinitely in an MVar operation I solved the Halting Problem: <<loop>> putting MVar... putted MVar As can be seen, the putMVar is executed successfully. So why do I get the message: "thread blocked indefinitely in an MVar operation"? Note that if I change the action to a normal error the message disappears. I discovered this bug when hunting for another one. I have a Haskell web-server where one of the request handlers contained a loop. All exceptions thrown by handlers are caught and logged. When executing the looping handler I noticed ~0% CPU usage so I assumed that the handler wasn't actually looping because a NonTermination exception was thrown. However for some reason the NonTermination exception was not caught and logged. I haven't yet isolated this bug into a small test-case but when trying that I discovered the above. Regards, Bas

3 5

trouble building ghc-7.4 on Fedora 18 (devel) ARM
by Jens Petersen 04 May '12

04 May '12

Hi, I have been struggling to build ghc74 on ARM (ideally with llvm3) on Fedora 18 (the current development tree). After applying 4 recent ARM patches from Debian the ghc-7.4.1 build gets to: : "inplace/bin/ghc-stage1" -H32m -O -package-name base-4.5.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.4.0.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O2 -no-user-package-conf -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/dist-install/build/GHC/Event/Clock.hs -o libraries/base/dist-install/build/GHC/Event/Clock.o [parallel build line removed] /usr/bin/ld: error: /tmp/ghc5703_0/ghc5703_0.o uses VFP register arguments, libraries/base/dist-install/build/GHC/Event/Clock.o does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc5703_0/ghc5703_0.o collect2: error: ld returned 1 exit status make[1]: *** [libraries/base/dist-install/build/GHC/Event/Clock.o] Error 1 (full build log at: http://arm.koji.fedoraproject.org/koji/getfile?taskID=723311&name=build.log and more details at http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=723311) I gather that it builds on Debian so I am not quite why it is failing on Fedora. To see if ghc-7.4.2pre is any better I tried building ghc-7.4.1.20120416 too (without any ARM patches), which gets a lot further, to using llvm: "inplace/bin/ghc-stage1" -H32m -O -package-name array-0.4.0.0 -hide-all-packages -i -ilibraries/array/. -ilibraries/array/dist-install/build -ilibraries/array/dist-install/build/autogen -Ilibraries/array/dist-install/build -Ilibraries/array/dist-install/build/autogen -Ilibraries/array/include -optP-include -optPlibraries/array/dist-install/build/autogen/cabal_macros.h -package base-4.5.1.0 -XHaskell98 -XMultiParamTypeClasses -XFlexibleContexts -XFlexibleInstances -XTypeSynonymInstances -XDeriveDataTypeable -XStandaloneDeriving -XRank2Types -XMagicHash -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XCPP -O2 -no-user-package-conf -rtsopts -odir libraries/array/dist-install/build -hidir libraries/array/dist-install/build -stubdir libraries/array/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/array/./Data/Array/IO/Internals.hs -o libraries/array/dist-install/build/Data/Array/IO/Internals.o libraries/array/Data/Array/IO/Internals.hs:2:16: Warning: -#include and INCLUDE pragmas are deprecated: They no longer have any effect Instruction referencing instruction not embedded in a basic block! %ln2ulc = getelementptr inbounds i32* %Sp_Arg, i32 3 %ln2uld = ptrtoint i32* %ln2ulc to i32 Instruction does not dominate all uses! %ln2ulc = getelementptr inbounds i32* %Sp_Arg, i32 3 tail call cc10 void @stg_ap_ppp_fast(i32* %Base_Arg, i32* %ln2ulc, i32* %ln2uk8, i32 %ln2uky, i32 ptrtoint (%templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfDataFunDepzuzddData_closure_struct* @templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfDataFunDepzuzddData_closure to i32), i32 %ln2ul2, i32 %ln2ul6, i32 %SpLim_Arg) nounwind Broken module found, compilation aborted! 0 libLLVM-3.0.so 0x4058f348 1 libLLVM-3.0.so 0x4058f7b4 2 libc.so.6 0x4150a0b0 __default_sa_restorer_v2 + 0 3 libc.so.6 0x41508c7c gsignal + 64 4 libc.so.6 0x4150a2bc abort + 432 5 libLLVM-3.0.so 0x406f88e0 6 libLLVM-3.0.so 0x406e7678 llvm::FPPassManager::runOnFunction(llvm::Function&) + 440 7 libLLVM-3.0.so 0x406e7760 llvm::FPPassManager::runOnModule(llvm::Module&) + 48 8 libLLVM-3.0.so 0x406e733c llvm::MPPassManager::runOnModule(llvm::Module&) + 396 9 libLLVM-3.0.so 0x406e7484 llvm::PassManagerImpl::run(llvm::Module&) + 108 10 opt 0x00014528 main + 2268 11 libc.so.6 0x414f2dd0 __libc_start_main + 272 Stack dump: 0. Program arguments: opt /tmp/ghc22413_0/ghc22413_0.ll -o /tmp/ghc22413_0/ghc22413_0.bc -O2 1. Running pass 'Function Pass Manager' on module '/tmp/ghc22413_0/ghc22413_0.ll'. 2. Running pass 'Module Verifier' on function '@seuH_info' make[1]: *** [libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.o] Error 1 (full log at http://arm.koji.fedoraproject.org/koji/getfile?taskID=746853&name=build.log, more details at http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=746853) I haven't tried HEAD yet though the results at http://darcs.haskell.org/ghcBuilder/builders/kgardas-linux-arm-head/index.h… are not too encouraging. Perhaps I will try building ghc74 on ARM without llvm first, and maybe on Fedora 17 too? Anyway thoughts on how to proceed? Thanks, Jens ps There is actually a proposal to make ARM a Fedora 18 Primary Architecture - though personally I feel it is a bit too early yet - if that happens then this would become a more serious problem, though I know ARM is still not a Tier 1 ghc platform.

3 6