- Glasgow-haskell-users

SIGALRM, SIGVTALRM, and third party libraries
by Bryan O'Sullivan 09 Sep '10

09 Sep '10

I spent some time this morning trying to use HDBC-mysql to talk to a database. It uses the C mysql bindings, which talks over a blocking socket to the database server. Not surprisingly, it fails reliably when the thread it's running in is hit by an RTS-initiated alarm signal. I've managed to make the code *appear* to work successfully with some hacking: - Run in a bound thread - Use pthread_sigmask to temporarily block SIGALRM and SIGVTALRM to *only* this thread while issuing the sensitive native calls - Profit? What I am wondering is if there's a practical downside to doing this. Am I going to accidentally kill something? This is a very important gap in the usability of GHC with native libraries, and if this approach actually turns out to be safe in practice, that would be wonderful.

5 11

Compiling base with custom compilation script
by Victor Nazarov 06 Sep '10

06 Sep '10

I have some custom compilation script that uses GHC API The aim is to extract some info from every module in dependency graph and to write this information to the file lying near module-file. Script goes like this: main :: IO () main = do args <- getArgs defaultErrorHandler defaultDynFlags $ runGhc (Just libdir) $ do sdflags <- getSessionDynFlags (dflags, fileargs', _) <- parseDynamicFlags sdflags (map noLoc args) when (null fileargs') $ ghcError (UsageError "No input files.") _ <- setSessionDynFlags dflags let fileargs = map unLoc fileargs' targets <- mapM (\x -> guessTarget x Nothing) fileargs setTargets targets mgraph <- depanal [] False let files = filter (not . isSuffixOf "boot") . map (extractPath . ms_location) $ mgraph extractPath l = fromMaybe (ml_hi_file l) (ml_hs_file l) setTargets [] flip mapM_ files $ \file -> do core <- compileToCoreSimplified file HscTypes.liftIO $ let info = show (generateInfo core) fp = replaceExtension file ".info" putStrLn $ "Writing " ++ fp writeFile fp program The problem is processing base-4 package. I'd like to run something like: $ cd base-4.2.0.1 $ compiler -fglasgow-exts -cpp -package-name base -I./include Prelude.hs and to receive Prelude.info and .info files for every other modules that prelude depends on. At first I've got errors like missing .h file. I've downloaded GHC source distribution and get missing headers from GHC. But now I get errors like "trying to load Prelude module which is not loadable". I don't remember the exact text and I have no access to my developing-machine. I think it's caused by circular dependencies between modules. And I think my compilation script is not quite correct for this case. What do you think? -- Victor Nazarov

2 1

Confusing warnings from GHC HEAD
by Bryan O'Sullivan 05 Sep '10

05 Sep '10

I get a few dozen of these when building the text package, and they weren't present in 6.12 or earlier: SpecConstr Function `$wa1{v X5A2} [lid]' has three call patterns, but the limit is 2 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations There are a few aspects to this that I find surprising. - I can't do anything with the Core name. - My cabal file contains -fspec-constr-count=5 just to be safe, but it doesn't help. I can't tell whether this is the compiler going a little off into the weeds, or whether I'm doing something wrong, but I appear to be unable to make the message go away. Thanks, Bryan.

4 6

Difference between optimized and non-optimized version
by Mitar 02 Sep '10

02 Sep '10

Hi! I am attaching a program which locks (throws an exception <<loop>>) when compiled like: ghc --make -threaded -main-is Test.main Test.hs -o test and doesn't lock when compiled with ghc --make -threaded -main-is -O2 Test.main Test.hs -o test This should probably not happen. I am using 6.12.3 on Linux x86_64. Best regards Mitar

2 1

FFI, signals and exceptions
by Edward Z. Yang 02 Sep '10

02 Sep '10

Hello all, I am currently investigating techniques to nicely handle SIGINTs when FFI code is running. Yes, I know it sounds kind of crazy. Ignoring the problems of cleaning up the unceremoniously terminated C computation, I'm having difficulty getting the FFI to /stop/ running when I get the signal. I currently have some code like this: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28422#a28422 which doesn't work, and which you guys can probably tell me doesn't work. :-) Throwing exceptions from the signal handler also doesn't work. Any suggestions for GHC source code to look at / techniques to try? Cheers, Edward

3 16

HEAD unbuildable
by Johan Tibell 31 Aug '10

31 Aug '10

I'm having trouble building HEAD, to the point where even running "make clean" fails. $ make clean && make maintainer-clean make -r --no-print-directory -f ghc.mk clean CLEANING=YES "rm" -rf inplace "rm" -rf "rm" -rf docs/users_guide/users_guide docs/users_guide/users_guide.pdf docs/users_guide/users_guide.ps "rm" -rf docs/users_guide/users_guide.xml docs/users_guide/what_glasgow_exts_does.gen.xml "rm" -rf docs/man/ghc.1 docs/man/flags.xsl docs/man/flags.xml "rm" -rf libraries/Cabal/doc/Cabal libraries/Cabal/doc/Cabal.pdf libraries/Cabal/doc/Cabal.ps "rm" -rf utils/unlit/dist "rm" -rf inplace/lib/ "rm" -rf utils/hp2ps/dist "rm" -rf inplace/bin/hp2ps "rm" -rf driver/mangler/dist inplace/lib/ "rm" -rf driver/split/dist inplace/lib/ "rm" -rf utils/genprimopcode/dist "rm" -rf inplace/bin/ "rm" -rf libffi/build libffi/stamp.ffi.* libffi/dist-install "rm" -rf includes/dist-derivedconstants "rm" -rf inplace/bin/mkDerivedConstants "rm" -rf includes/dist-ghcconstants "rm" -rf inplace/bin/mkGHCConstants "rm" -rf includes/ghcautoconf.h includes/ghcplatform.h includes/GHCConstants.h includes/DerivedConstants.h "rm" -rf rts/dist "rm" -rf bindisttest/"install dir" bindisttest/HelloWorld bindisttest/HelloWorld.o bindisttest/HelloWorld.hi bindisttest/output "rm" -rf utils/ghc-cabal/dist bootstrapping "rm" -rf utils/ghc-cabal/dist-dummy-ghc "rm" -rf inplace/bin/dummy-ghc "rm" -rf utils/genapply/dist "rm" -rf inplace/bin/ "rm" -rf utils/haddock/dist "rm" -rf utils/haddock/doc/haddock utils/haddock/doc/haddock.pdf utils/haddock/doc/haddock.ps make[1]: *** No rule to make target `clean_libraries/dph/dph-base', needed by `clean_libraries/dph'. Stop. make: *** [clean] Error 2 A normal make fails on some profiling thingy. -- Johan

3 3

RE: late optimization of typeclass callers
by christian Hoener zu Siederdissen 27 Aug '10

27 Aug '10

Thanks that is *exactly* the problem I am having. The missing line breaks are kind of weird. I will try the newest head (which will mean getting about 20 libs to compile...) and report back. I left the core out intentionally because the vector library tends to produce ugly core when it can not optimize. Should the problem *not* go away with HEAD (right now I am using 6.12.3) then I will create a self-contained set of files that reproduce the problem. Thanks again, Christian ----- Original message ----- > It's hard to read your code because the line breaks have been removed. > Moreover I think your code depends on some unspecified Hackage package. > And I couldn't find the enclosed Core dumps. Nor do you specify which > version of GHC you are using. > > Still I believe that the nub is this. You have a class with a default > method declaration > > class FoldFunctions a where > opt = <blah> > > and you get different behaviour if you say > > instance FoldFunctions Int > from > instance FoldFunctions Int where > opt = <blah> > > That's surprising because the second case simply fills in the method > with the identical code to the code in the class declaration. > > Is that right? > > If so, I think you might want to try the HEAD. Can you do that (use a > binary snapshot). I think I fixed this default-method-inlining stuff so > that there is no difference between the above two. > > But I could have failed, or there could be something else going on in > your example. > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of > Christian Höner zu Siederdissen | Sent: 26 August 2010 10:36 > | To: Glasgow-Haskell-Users > | Subject: late optimization of typeclass callers > | > | Hi, > | > | I do have the problem that my code is not completely optimized. We > begin with | > | -- Ring.hs > | class Ring a where > | rmult :: a -> a -> a > | zero :: a > | > | -- PrimitiveArray.hs > | class PrimArrayOps a b where > | data PrimArray a b :: * > | unsafeIndex :: PrimArray a b -> a -> b > | > | -- PAInstances.hs > | -- for any 'a' of Data.Primitive.Types by Roman, have unboxed arrays > instance | (Prim a) => PrimArrayOps where > | data PrimArray (Int,Int) a = PaIIxI {-# UNPACK #-} !(Int,Int) {-# > UNPACK #- | } !ByteArray > | unsafeIndex (PaIIxI (mI,mJ) arr) (i,j) = {-# CORE "IIxIunsafeIndex" > #-} | case (i*(mJ+1)+j) of idx -> indexByteArray arr idx > | > | -- RNAfoldFunctions.hs > | -- VU.Unbox a, because of the vector package import > Data.Vector.Unboxed as VU | class (Ring a, VU.Unbox a, Prim a) => > FoldFunctions a where | opt = VU.foldl' rmult zero $ base turnertables > inp table table i j | > | base trnr inp m m1 i j = VU.zipWith rmult ms m1s where > | cnt = j-i-2 -- TODO when to stop? > | ms = VU.map (\ik -> m `unsafeIndex` ik) $ VU.generate cnt (\k -> > | (i,i+k)) > | m1s = VU.map (\kj -> m1 `unsafeIndex` kj) $ VU.generate cnt (\k -> > | (k+1+i,j)) {-# INLINE multibranchCloseBase #-} > | > | > | > | If I now use this stuff... > | -- [1] > | instance Ring Int where > | rmult = min > | zero = 10000 > | instance FoldFunctions Int > | module MyProgram where > | main = do > | let val = opt trnr inp myM myM1 15 78 > | > | I get this core [1]. If I do this > | -- [2] > | instance Ring Int where > | rmult = min > | zero = 10000 > | instance FoldFunctions Int > | opt = VU.foldl' rmult zero $ base turnertables inp table table i j > module | MyProgram where main = do > | let myM = PrimArray of (Int,Int) with Int values > | ... > | let val = opt trnr inp myM myM1 15 78 > | > | Is there a way to get the program without an explicit FoldFunctions > instance | to specialize to the same Core as the second? The runtime > (Criterion was | used) is 7.1us (or worse) for [1] and 2.7us for [2]. I > could put nice INLINEs | everywhere but they do not help optimizing. > These functions run O(n^2) times, | with n between 100 and 10000. The > core shows that temporary arrays are even | created, filled, and then > the fold run over them. | > | So basically, can I get code running through several class instances > to be | optimized at the caller, where all instances are known? > Otherwise I could | live with [2], but as the code will almost always be > the same for | FoldFunctions instances, it would be really nice to be > able to use the | defaults that were defined on (Ring a, VU.Unbox a, > Prim a). | > | Thanks, > | Christian

1 0

late optimization of typeclass callers
by Christian Höner zu Siederdissen 27 Aug '10

27 Aug '10

Hi, I do have the problem that my code is not completely optimized. We begin with -- Ring.hs class Ring a where rmult :: a -> a -> a zero :: a -- PrimitiveArray.hs class PrimArrayOps a b where data PrimArray a b :: * unsafeIndex :: PrimArray a b -> a -> b -- PAInstances.hs -- for any 'a' of Data.Primitive.Types by Roman, have unboxed arrays instance (Prim a) => PrimArrayOps where data PrimArray (Int,Int) a = PaIIxI {-# UNPACK #-} !(Int,Int) {-# UNPACK #-} !ByteArray unsafeIndex (PaIIxI (mI,mJ) arr) (i,j) = {-# CORE "IIxIunsafeIndex" #-} case (i*(mJ+1)+j) of idx -> indexByteArray arr idx -- RNAfoldFunctions.hs -- VU.Unbox a, because of the vector package import Data.Vector.Unboxed as VU class (Ring a, VU.Unbox a, Prim a) => FoldFunctions a where opt = VU.foldl' rmult zero $ base turnertables inp table table i j base trnr inp m m1 i j = VU.zipWith rmult ms m1s where cnt = j-i-2 -- TODO when to stop? ms = VU.map (\ik -> m `unsafeIndex` ik) $ VU.generate cnt (\k -> (i,i+k)) m1s = VU.map (\kj -> m1 `unsafeIndex` kj) $ VU.generate cnt (\k -> (k+1+i,j)) {-# INLINE multibranchCloseBase #-} If I now use this stuff... -- [1] instance Ring Int where rmult = min zero = 10000 instance FoldFunctions Int module MyProgram where main = do let val = opt trnr inp myM myM1 15 78 I get this core [1]. If I do this -- [2] instance Ring Int where rmult = min zero = 10000 instance FoldFunctions Int opt = VU.foldl' rmult zero $ base turnertables inp table table i j module MyProgram where main = do let myM = PrimArray of (Int,Int) with Int values ... let val = opt trnr inp myM myM1 15 78 Is there a way to get the program without an explicit FoldFunctions instance to specialize to the same Core as the second? The runtime (Criterion was used) is 7.1us (or worse) for [1] and 2.7us for [2]. I could put nice INLINEs everywhere but they do not help optimizing. These functions run O(n^2) times, with n between 100 and 10000. The core shows that temporary arrays are even created, filled, and then the fold run over them. So basically, can I get code running through several class instances to be optimized at the caller, where all instances are known? Otherwise I could live with [2], but as the code will almost always be the same for FoldFunctions instances, it would be really nice to be able to use the defaults that were defined on (Ring a, VU.Unbox a, Prim a). Thanks, Christian

2 1

__emutls_get_address link problem
by Christian Maeder 26 Aug '10

26 Aug '10

Hi, I've created a sparc solaris installation of ghc-6.12.3 using gcc-4.3.3 However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts! With ghc-6.12.1 and gcc-4.x.y (x < 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. Does anybody have an explanation or proposal to fix this? Thanks Christian Linking Hello ... /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o): In function `scavenge_until_all_done': GC.c:(.text+0x178): undefined reference to `__emutls_get_address' GC.c:(.text+0x204): undefined reference to `__emutls_get_address' GC.c:(.text+0x250): undefined reference to `__emutls_get_address' GC.c:(.text+0x27c): undefined reference to `__emutls_get_address' GC.c:(.text+0x338): undefined reference to `__emutls_get_address' /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o):GC.c:(.text+0x408): more undefined references to `__emutls_get_address' follow collect2: ld returned 1 exit status -bash-3.00$ gcc -v Reading specs from /export/local/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77: (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.4 gcc used for Building ghc-6.12.3 Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC)

4 8

SIGPIPE in the GHC runtime
by Brian Bloniarz 26 Aug '10

26 Aug '10

The GHC runtime ignores SIGPIPE by setting the signal to SIG_IGN. This means that any subprocesses (created via System.Process or otherwise) will also have their SIGPIPE handler set to SIG_IGN; I think this might be a bug. The Python runtime does the same thing, there's a good explanation of the drawbacks in: http://bugs.python.org/issue1652 IMHO the simplest fix is the patch below: simply avoid SIG_IGN, instead install a handler which does nothing. This way, an exec() restores the handler to SIG_DFL. I've included a testcase too. Do people think this is the way to go? I think the alternative is the approach Python took: patch the various bits of code that fork&exec and have them restore the signal handler manually. --- diff -rN old-ghc/rts/posix/Signals.c new-ghc/rts/posix/Signals.c 472a473,477 > static void > ignoreSigPipe(int sig) > { > } > 528,529c533,535 < // ignore SIGPIPE; see #1619 < action.sa_handler = SIG_IGN; --- > // ignore SIGPIPE; see #1619. Don't use SIG_IGN since that'd > // be inherited by any children that get fork&exec'd. > action.sa_handler = &ignoreSigPipe; 531c537 < action.sa_flags = 0; --- > action.sa_flags = SA_RESTART; --- Testcase: diff -rN old-testsuite/tests/ghc-regress/rts/all.T new-testsuite/tests/ghc-regress/rts/all.T 86a87,88 > > test('exec_signals', [cmd_prefix('$MAKE exec_signals-prep && ./exec_signals_prepare')], compile_and_run, ['']) diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_child.c new-testsuite/tests/ghc-regress/rts/exec_signals_child.c 0a1,47 > #include <signal.h> > #include <stdio.h> > #include <errno.h> > > // Prints the state of the signal handlers to stdout > int main() > { > int open = 0, i; > sigset_t blockedsigs; > > printf("ChildInfo { masked = ["); > > sigprocmask(SIG_BLOCK, NULL, &blockedsigs); > for(i = 0; i < NSIG; ++i) > { > int ret = sigismember(&blockedsigs, i); > if(ret >= 0) > { > if(!open) > open=1; > else > printf(","); > printf("(%d,%s)", i, ret == 1 ? "True" : "False"); > } > } > printf("], handlers = ["); > > open = 0; > for(i = 0; i < NSIG; ++i) > { > struct sigaction old; > if(sigaction(i, NULL, &old) >= 0) > { > if(!open) > open=1; > else > printf(","); > > printf("(%d,%s)", i, > old.sa_handler == SIG_IGN ? "Ignored" : > (old.sa_handler == SIG_DFL ? "Default" : "Handled")); > } > } > printf("]}"); > > return 0; > } diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals.hs new-testsuite/tests/ghc-regress/rts/exec_signals.hs 0a1,20 > import System.Process > import System.Posix.Signals > import Control.Monad(when) > > data SigState = Ignored | Default | Handled > deriving (Eq, Read, Show) > > data ChildInfo = ChildInfo { > masked :: [(Int,Bool)], > handlers :: [(Int, SigState)] } > deriving (Read, Show) > > main = do out <- readProcess "./exec_signals_child" [] "" > let ci = read out :: ChildInfo > blockedSigs = [x | (x, True) <- masked ci] > ignoredSigs = [x | (x, Ignored) <- handlers ci] > when (not $ null blockedSigs) $ > putStrLn ("signals " ++ show blockedSigs ++ " are blocked") > when (not $ null ignoredSigs) $ > putStrLn ("signals " ++ show ignoredSigs ++ " are ignored") diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c new-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c 0a1,29 > #include <signal.h> > #include <stdio.h> > #include <errno.h> > #include <string.h> > > // Invokes a process, making sure that the state of the signal > // handlers has all been set back to the unix default. > int main(int argc, char **argv) > { > int i; > sigset_t blockedsigs; > struct sigaction action; > > // unblock all signals > sigemptyset(&blockedsigs); > sigprocmask(SIG_BLOCK, NULL, NULL); > > // reset all signals to SIG_DFL > memset(&action, 0, sizeof(action)); > action.sa_handler = SIG_DFL; > action.sa_flags = 0; > sigemptyset(&action.sa_mask); > for(i = 0; i < NSIG; ++i) > sigaction(i, &action, NULL); > > execv(argv[1], argv+1); > fprintf(stderr, "failed to execv %s\n", argv[1]); > return 0; > } diff -rN old-testsuite/tests/ghc-regress/rts/Makefile new-testsuite/tests/ghc-regress/rts/Makefile 29a30,32 > exec_signals-prep:: > $(CC) -o exec_signals_child exec_signals_child.c > $(CC) -o exec_signals_prepare exec_signals_prepare.c

3 8