If you are interested in Haskell generally or the Glasgow Haskell Compiler (GHC) in particular, you may want to have a look at the latest issue of the biannual GHC status updates. It includes a summary of our recent progress in the Data Parallel Haskell project.
After much digging through otool output and tracing Haskell code with dtrace, log messages, and gdb, I finally found the cause of the SIGBUS errors with ghci on Snow Leopard. At the end, only a tiny change was required[1]: the homegrown dynamic linker of ghci had simply ignored a relocation type that ld on Snow Leopard chose to use.
What this really shows again is that re-implementing parts of basic infrastructure in an ad hoc manner always comes back to bite you. Such infrastructure is usually full of low-level, platform-dependent details, which you are bound to get wrong once in a while and then it can be rather involved to find the problem. In this case, the relocation of the memory access of a bit of C code in GMP, reading a global variable, went wrong. As a result, the wrong memory location was accessed, which happened to contain a NULL pointer. Upon dereferencing the NULL, the program crashed. All of this was further obscured by the fact that the homegrown linker approach of ghci implies that we have two copies of the basic libraries in memory and in use at the same time. One copy has been statically linked with the ghc executable and the second copy is dynamically loaded by ghci. The relocation in the statically linked copy was perfectly fine, but the relocation in the dynamically loaded one was broken. [1] http://www.haskell.org/pipermail/cvs-ghc/2009-October/050863.htmlGHC's testsuite[1] contains a test encoding001 (in the I/O library section) that generates files in various unicode encodings including one using UTF-8 with byte order markers, namely encoding001.utf16.utf8_bom. On Mac OS X 10.6 (Snow Leopard), this file causes the indexing process of Spotlight to hang. More precisely, the mds (meta dataserver) process appears to go into a loop (eating all cycles of one processor core) — it appears to hang in the library libmecap trying to parse what it probably believes to be Japanese or Chinese text.
Interestingly, the file command regards the file to be "Unicode text, UTF-32, big-endian".
Here's a very simple Haskell program:
import System.Console.Readline
main :: IO ()
main = do
putStr "Key: "
k <- readKey
putStrLn [k]
Looks pretty innocent, right? And it runs just fine with runhaskell. But as soon as you try to compile it with ghc and run it, Segmentation Faults occur. This was a bug that recently bit me with my hlean program.
What is the difference between the two? runhaskell invokes ghci, which makes additional readline initializations before handing it off to your main. The documentation is non-existent, so here is what you need to do in case you come across the same problem:
import System.Console.Readline
main :: IO ()
main = do
initialize -- System.Console.Readline.initialize :: IO ()
putStr "Key: "
k <- readKey
putStrLn [k]
Again, you test it using runhaskell and everything works fine. Except when you build and run it, the prompt just sits there - no matter how many times you hit that key - until you hit the carriage return (for the younger generation, that's [Enter]). Turns out that initializing Readline is not enough, ghc and ghci have different buffering modes. After even more struggling which you now don't have to suffer through, here's the final solution:
import System.Console.Readline
import System.IO
main :: IO ()
main = do
initialize -- System.Console.Readline.initialize :: IO ()
hSetBuffering stdin NoBuffering -- System.IO
hSetBuffering stdout NoBuffering -- System.IO
putStr "Key: "
k <- readKey
putStrLn [k]
Hope I saved some poor googler some time and stress - I know I would have appreciated finding a post like this earlier. Kudos to pejo and dcoutts on #haskell irc for helping me sort this out.
