- Glasgow-haskell-users

How to debug a segfault.
by David Brown 01 Mar '07

01 Mar '07

I'm developing a program with GHC-6.6. I've been on amd64, and haven't had problems, but now when I run the program on on x86 (after cleaning and recompiling), I'm getting a segfault. gdb isn't very helpful at all: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212873040 (LWP 26946)] 0x080b45b8 in s2EI_info () (gdb) bt #0 0x080b45b8 in s2EI_info () #1 0x081757a8 in ?? () #2 0x00000004 in ?? () #3 0xb7875278 in ?? () I am using some various bindings to some C libraries, some I have written and some written by others. But, I'm not able to figure out where to even begin looking for the problem. Any advice on how I might be able to better debug this? Would compiling unregistered help (I'll have to figure out how to build libraries for that)? Thanks, David Brown

4 6

TFP 2007: Last Call for Participation
by TFP 2007 28 Feb '07

28 Feb '07

Dear Colleagues, The deadline to register for TFP 2007 is quickly approaching. You may register at: http://cs.shu.edu/tfp2007/registration.html . Also, please be advised that the deadline to make hotel reservations at the guaranteed rate for TFP 2007 participants is also quickly approaching. Hotel information can be found at: http://cs.shu.edu/tfp2007/accomodations.html . You may browse the program and schedule for TFP 2007 at: http://cs.shu.edu/tfp2007/schedule.html . We look forward to seeing you in NYC!!! Cheers, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

using a stage1 as a compiler for a later ghc?
by Isaac Dupree 28 Feb '07

28 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm on a system with main ghc = 6.4.2. I've built a ghc 6.6 stage1. Is there any problem using that ghc-inplace as a compiler for GHC HEAD? (which is done e.g. by ./configure - --with-ghc=/home/isaac/hardly-mine-at-all/build/ghc-6.6/compiler/stage1/ghc-inplace ?) (which I want to do because, theoretically 6.6 should be faster here, since it supports -fasm unlike the ubuntu-edgy-powerpc-ghc-6.4.2, and also considering how my gcc likes to crash randomly a few times during anything as extensive as compiling ghc...) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5LXeHgcxvIWYTTURAoo2AKDHUAo+7759LwBbXh5cP7zklMfKkgCdGoK9 ZQvjhkVTVUt512kpMPquDzc= =zn7+ -----END PGP SIGNATURE-----

2 1

Re: GHC on Cray XMT?
by Peter Tanski 27 Feb '07

27 Feb '07

Chad Scherrer wrote: > The new Cray XMT seems to target exactly the same kind of analytic > problems where Haskell excels: > > http://www.cray.com/products/xmt/ > > I'm not a hardware guy, but this seems like a natural fit with the > recent advances in SMP Haskell. I know some compiler experts, but none > of them have experience with Haskell. > > Can anyone tell me how big an undertaking it would this be to get GHC > going on one of these? It seems to me like the fact that the absence > of cache on XMT processors should simplify things, since there are > less issues reasoning about locality. Porting GHC to a new architecture may be easy or very involved. See http://hackage.haskell.org/trac/ghc/wiki/Building/Porting. Porting to the Cray XMT would appear to be very difficult but a real Plum!. I am not sure how close its UNICOS operating system is to BSD (GHC has ports to FreeBSD and OpenBSD)--that is just the main programming environment; working with the processors may require a smaller microkernel environment. According to the XMT Datasheet the main programming is done on Linux-based nodes. Linux is GHC's "home" OS, so that would seem to make it a little easier. For an experience porting Glasgow Parallel Haskell (GPH) to an MPP, you might want look at the work of Kei Davis (http://www.c3.lanl.gov/ ~kei/), who ported an older version of GHC to the Thinking Machines CM-5 SPMD (http://www.c3.lanl.gov/~kei/lanlwork.html and especially, "MPP Parallel Haskell (Preliminary Draft)", 1996, at http:// www.c3.lanl.gov/~kei/ifl96.ps) Kei Davis's work is also referenced on the Glasgow Parallel Haskell site, under "PORTS" (http:// www.macs.hw.ac.uk/~dsg/gph/) I mention his work in particular because the CM-5 port involved a slightly new (Solaris-like) OS and a specialised message passing system, CMMD, instead of PVM used by Glasgow Parallel Haskell. That would be quit a lot of work since you would have to modify the RTS--the old GUM (Parallel Haskell support) stuff is still in there but it is somewhat bit-rotted. The amount of work required might get worse or better as GHC's future is native assembly output--worse, because you would have to work through the assembly code and efficient C-code generation would require more work with a nasty Perl script called the Mangler; better, depending on whether someone essentially rewrites the ugly spider-web of code in GHC's Native Code Generator (NCG). But all this stuff is for a "native" port: if you have access to an XMT, you might want to simply follow the directions on Porting GHC to a new platform (http://hackage.haskell.org/trac/ghc/wiki/Building/ Porting#PortingGHCtoanewplatform) and see what problems you run into. Cheers, Peter Tanski

1 0

Re: status of GreenCard support
by Peter Tanski 27 Feb '07

27 Feb '07

> Jefferson Heard wrote: >> some simple fix that would make code generated by GreenCard work, >> or is there >> some alternative tool that will make it work? What's the status >> of C2HS? Marc Weber wrote: > When using cabal and GreenCard it might be the case that you have to > tweak setup.hs to add --libdir parameters. Probably it would be better > to update cabal. Maybe I've missed a point to configure it correctly? > If I can save you some minutes by dropping you me quick setup.hs hack > let me know it. I should have answered this in before, sorry. GHC has not supported GreenCard since version 6.2. See http://www.haskell.org/haskellwiki/ Libraries_and_tools/Interfacing_other_languages and http://www.mail-archive.com/haskell@haskell.org/msg14004.html I ran into that problem while attempting to get gcjni-1.2 to work with GHC 6.4 awhile ago, got annoyed, and appended the warning to the Haskell Wiki page lest others ran into the same problem. The Alastair Reid's successor to GreenCard, based on Template Haskell, hasn't been finished yet (or perhaps it is dead?). For more automatic configuration, you might consider Template Haskell: see Ian Lynagh's "Template Haskell: A Report From the Field", at http:// web.comlab.ox.ac.uk/oucl/work/ian.lynagh/papers/ . There are still configuration parameters in the GHC build system for GreenCard but from what I have seen of the rest it seems that you would have to write your own support for the old _casm_ ffi bindings back into the source code practically from scratch (perhaps grabbing an archive of 6.1 would give you a better start). Cheers, Peter Tanski

1 0

GHC on Cray XMT?
by Chad Scherrer 27 Feb '07

27 Feb '07

The new Cray XMT seems to target exactly the same kind of analytic problems where Haskell excels: http://www.cray.com/products/xmt/ I'm not a hardware guy, but this seems like a natural fit with the recent advances in SMP Haskell. I know some compiler experts, but none of them have experience with Haskell. Can anyone tell me how big an undertaking it would this be to get GHC going on one of these? It seems to me like the fact that the absence of cache on XMT processors should simplify things, since there are less issues reasoning about locality. Thanks! Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 1

Re: hasktags - small patch
by Claus Reinke 23 Feb '07

23 Feb '07

> The good reason is that you do not actually want to have to specify > all the options that you need to get your program to compile, merely > to get tag information. To generate the tags for dazzle using ghci > I need to use > echo ":ctags"| ghci -v0 Main.hs -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec > whereas with hasktags I'd just use > hasktags *.hs yes, that's a general problem with using ghci in real projects. of course, *.hs isn't always sufficient to find the files for a project, and the files might need pre-processing, etc. but there are advantages to not having a proper parser and just treating a project as a collection of files, to be found by globbing or find, and to be scanned for some simple patterns. it means that one can get tags for incomplete projects, even with errors in the files. but as far as the extra options are concerned, i tend to create a miniscript to set the options for a project, and use the fact that --make/--interactive switch between ghc and ghci: #!/bin/sh ghc ${mode:-"--make"} $@ -i../lib -i../lib/DData/ -fglasgow-exts -L../ -lsmilec then, to build with ghc: ./myghc.sh Main.hs or, to invoke ghci: mode="--interactive" ./myghc.sh Main.hs or, to generate tags from outside ghci (this might be worth a command alias): echo ":ctags" | mode="--interactive -v0" ./myghc.sh Main.hs such scripts wouldn't be needed if ghc/ghci could be started from cabal files - you'd just set your options and paths once and for all (there's a ticket for that somewhere). once I'm set up in ghci, as I tend to be while hacking, it is of course just :ctags rather than finding a shell and typing find . -name *hs | xargs hasktags or somesuch;-) > What I would *really* like is a Haskell parser in Exuberant Ctags... > that would mean I could directly use vim's taglist extension. another good point, but: exuberant ctags is just another tagfile generator. it is very good for other languages, but *really* teaching it about Haskell is non-trivial. whereas ghci or ghc-api already know how to type things and all the rest of Haskell's static semantics, in addition to parsing things.. as for using taglist: do you mean the vim function taglist, which gives you a dictionary with information associated with a tag? so you are probably interested in extra information about tags, beyond source location. (*) it should be a lot easier to expand the information generated by :ctags than to add a Haskell parser/type checker to exuberant ctags. the format is simply a comment (to protect old vi from choking on the extra info) followed by a list of extra fields (the dictionary) for each tag. see ":help tags-file-format" in vim, the third variant of the format. the only reasons i didn't do that right away was (a) it was my first serious attempt at using ghc api/extending ghci (Simon M had to do some reworking of my submitted code;-) and (b) i don't know how to use that kind of info in the emacs branch. have a look at ghc/compiler/ghci/InteractiveUI.hs, around listTags/TagInfo. if one knows where to get it, one could add info there (eg, the type of the tag, or whether the tag is a type/class/function/module/whatever). and the extra info ought to be written to the tags file, in collateAndWriteTags (simply ignore the extra info when writing the emacs tag file). hth, claus (*) if you want to go for broke, try ":help cursorhold-example" in vim. that will keep a preview window with the source-location of any tag your cursor remains on for long enough. so you might see the type declaration, or you might see the data type constructors belonging to a type, or .. i haven't used this as a default myself, but it is worth looking at at least once!-)

3 4

status of GreenCard support
by Jefferson Heard 22 Feb '07

22 Feb '07

Hi all, I'm working on wrapping nVidia's CUDA framework for parallel computation to use with GHC and I recalled seeing something that said GreenCard was not working with GHC 6.6, the latest version. Is that correct? If so, is there some simple fix that would make code generated by GreenCard work, or is there some alternative tool that will make it work? What's the status of C2HS? -- Jeff

2 1

-fallow-incoherent-instances not working
by Marc Weber 22 Feb '07

22 Feb '07

I'm trying to learn more about HList. While setting up a small test application I got the following error.. ghc(i) tells me to add -fallow-incoherent-instances but doesn't recognize it ? Is this a bug? marc@localhost /pr/haskell/test/HList $ ghci -package HList HListTestMain.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package HList-0.1 ... linking ... done. [1 of 2] Compiling HListTest.HList ( HListTest/HList.hs, interpreted ) HListTest/HList.hs:12:11: Overlapping instances for HOccursMany (Maybe Int) (HCons t (HCons t1 (HCons [Char] (HCons (Maybe t2) HNil)))) arising from use of `hOccursMany' at HListTest/HList.hs:12:11-24 Matching instances: instance [overlap ok] (HOccursMany e l, HList l) => HOccursMany e (HCons e' l) -- Defined in HOccurs instance [overlap ok] (HOccursMany e l, HList l) => HOccursMany e (HCons e l) -- Defined in HOccurs (The choice depends on the instantiation of `t, t1, t2' Use -fallow-incoherent-instances to use the first choice above) In the expression: hOccursMany l1 In the second argument of `($)', namely `(hOccursMany l1 :: [Maybe Int])' In the expression: print $ (hOccursMany l1 :: [Maybe Int]) Failed, modules loaded: none. Prelude> Leaving GHCi. marc@localhost /pr/haskell/test/HList $ cat HListTest/HList.hs {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-incoherent-instances #-} -- <<<<<<<<<<<< given here module HListTest.HList where import HList l1 = 2 .*. 3 .*. "abc" .*. (Just 4) .*. HNil hlistTest = do print $ 2 .*. HNil print $ (hOccursMany l1 :: [Maybe Int]) marc@localhost /pr/haskell/test/HList $ Marc

1 1

Debugging concurrent program - no threads apparently running, but RTS still doing something.
by Alistair Bayley 22 Feb '07

22 Feb '07

Below is a test case for a threading problem I can't figure out. It models a socket server (here I've replaced the socket with an MVar, to keep it simple). The idea is to have a listener which accepts incoming requests on the socket. When one arrives, it forks a handler thread to deal with the request, and returns to listening on the socket. The handler thread is run in parallel with a timeout thread. In the test case below, the handler takes too long, so the timeout thread completes and kills the handler. The problem is that when the main thread ends, the RTS doesn't stop for another 6 or so seconds. The only thread that runs this long is the handler (waitFor (secs 8.0)) but it has already been killed. So I'm scratching my head a bit. Also, any pointers to better techniques for designing and debugging concurrent code are appreciated (is there a better way than putStrLn?) Platform: ghc-6.6, Windows XP. Thanks, Alistair --------------------------------------------------------------------- module Main where import Prelude hiding (catch) import Control.Concurrent import Control.Exception import System.IO secs :: Float -> Int secs n = round (n * 1000000) -- e.g. waitFor (secs 25) waitFor n = debug ("waitFor start " ++ show ((fromIntegral n) / 1000000.0)) >> threadDelay n >> debug ("waitFor end " ++ show ((fromIntegral n) / 1000000.0)) debug msg = myThreadId >>= ( \t -> putStrLn $ (show t) ++ ": " ++ msg ) -- Thread 1 - start server then send message main = do hSetBuffering stdout LineBuffering blockingInput <- newEmptyMVar -- like a socket; accept on a socket blocks listnr <- forkIO (listener blockingInput) putMVar blockingInput "hello" waitFor (secs 2.0) debug "main: done" -- Thread 2 - listener. -- Blocks on input; when input arrives, starts handler thread. listener blockingInput = do msg <- takeMVar blockingInput serveRequest msg -- in a real server we'd loop: --listener blockingInput debug "listener: done" -- Start threads 3 and 4 - handler and timeout. serveRequest msg = do let acquire = return () let release _ = debug "handler release action" forkIO (runTimeout 0.1 acquire release (handler msg)) return () handler msg _ = do debug ("handler start: " ++ msg) catch (waitFor (secs 8.0) >> debug "handler end") (\e -> debug ("Exception: " ++ (show e)) >> throwIO e) runTimeout timeout acquire release action = do handlerTid <- myThreadId -- Use this to ensure the timeout thread doesn't start before the handler -- i.e. give the handler a chance to start. startTimeout <- newEmptyMVar timeoutTid <- forkIO (runTimeoutThread startTimeout timeout handlerTid) bracket acquire ( \a -> release a >> killThread timeoutTid ) ( \a -> do debug "runTimeout: start handler action" putMVar startTimeout True action a debug "runTimeout: end handler action" ) runTimeoutThread startTimeout timeout handlerTid = do takeMVar startTimeout debug "runTimeoutThread: start" waitFor (secs timeout) killThread handlerTid debug "runTimeoutThread: end"

2 2