2009/9/27 Paul Moore :

I'm still playing round with my random dieroll generation program. In doing so, I just hit a segmentation fault (I didn't think Haskell could *cause* a segfault!) I'm sure it's my code - I got this to compile by fiddling with types until the errors (which I didn't understand) went away. Certainly not the right way to code, I know, but never mind.

The problem is that I have *no idea* how to begin debugging this. In C, Python, or any other imperative language, I'd put traces in, etc. But in Haskell, I don't even know where to start.

I attach the code below. While help in the form of pointers to what I did wrong would of course be appreciated, what I'm really looking for is a pointer on how I'd find out for myself. (Hey! I just read the bit in the ghc manual which says if I am not using foreign or unsafe functions, a crash is a compiler bug. Did I find a compiler bug?)

My code is below. All I did is ghc --make hist_3d6.hs, then run hist_3d6.exe. This is ghc 6.10.4 on Windows Vista Home 32-bit.

Thanks for any help, Paul.

import System.Random.Mersenne import qualified Data.Map as Map import Data.Map (Map) import Data.List

takes :: Int -> [a] -> [[a]] takes n [] = [] takes n xs = take n xs : takes n (drop n xs)

sums :: Num a => Int -> [a] -> [a] sums n xs = map sum (takes n xs)

simulate :: Int -> IO [Double] simulate count = do  gen <- newMTGen Nothing  dice <- (randoms gen :: IO [Double])  return (take count dice)

histogram :: Ord a => [a] -> [(a,Int)] histogram = Map.assocs . foldl' f Map.empty  where   f m k = Map.insertWith' (+) k 1 m

simulation = do  lst <- simulate 100000  return lst  --return (histogram lst)

main = do  s <- simulation  putStrLn (show s) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

mersenne-random uses the FFI, so it's probably that. I just ran your code with mersenne-random-1.0 and didn't get a segfault. What version are you using?

On Sun, Sep 27, 2009 at 3:50 PM, Paul Moore wrote:

The problem is that I have *no idea* how to begin debugging this.

I've had great success debugging a large program by loading the Main module into ghci after setting GHC extensions, changing the search path, and setting break on errors. If you then place calls to the error function at the right location, and trace the execution, you'll be able to get a stack trace of the context in which the error function was called. John

On Sun, Sep 27, 2009 at 12:50 PM, Paul Moore wrote:

The problem is that I have *no idea* how to begin debugging this. In C, Python, or any other imperative language, I'd put traces in, etc. But in Haskell, I don't even know where to start.

One of the standard modules is Debug.Trace module, which does allow you to print information to the console. It just may come in an odd order and of course, it can change your program if you force evaluation. Under the covers it is really "unsafePerformIO $ putStrLn msg", i.e., it just prints to the console. I've found that forcing a flush on the output stream can be useful too, so I've defined my own trace before too. There is also the GHC debugger, which is best described in the user manual - read the section there to learn more. If you hadn't already received help on the list, either of these could be used to narrow down where the crash is occurring. Justin