haddock: segmentation fault

[Artyom.Kazak]

I was building GHC and got this error message from haddock.exe while haddock was processing Prim.hs. Haddock from GHC 6.12.1 processed this file without any errors. It's related to the ticket #3932.

"e:/ghcWork/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --title="ghc-prim-0.2.0.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt"   --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.2.0.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-split-objs --optghc=-package-name --optghc=ghc-prim --optghc=-XCPP --optghc=-XMagicHash --optghc=XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-XGenerics --optghc=-fno-warn-deprecated-flags --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hisuf --optghc=hi --optghc=-os
uf --optghc=o --optghc=-hcsuf --optghc=hc --source-module=src/%{MODULE/./-}.html --source-entity=src/%{MODULE/./-}.html   libraries/ghc-prim/./GHC/Bool.hs  libraries/ghc-prim/./GHC/Debug.hs  libraries/ghc-prim/./GHC/Generics.hs  libraries/ghc-prim/./GHC/Magic.hs  libraries/ghc-prim/./GHC/Ordering.hs  libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs  libraries/ghc-prim/./GHC/IntWord32.hs  libraries/ghc-prim/./GHC/IntWord64.hs  libraries/ghc-prim/./GHC/Tuple.hs  libraries/ghc-prim/./GHC/Types.hs  libraries/ghc-prim/./GHC/Unit.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs






                                        Ё`8☺А


                                                                            Segmentation fault/access violation in generated code

[igloo]

Thanks for the report. This bug has only shown up on Windows.

It seems to be caused by these inter-dependent patches:

Mon Mar 29 15:44:56 GMT Daylight Time 2010  Simon Marlow <marlowsd@gmail.com>
 * New implementation of BLACKHOLEs
Tue Apr  6 15:27:40 GMT Daylight Time 2010  Simon Marlow <marlowsd@gmail.com>
 * undo debugging code
Wed Apr  7 09:17:12 GMT Daylight Time 2010  Simon Marlow <marlowsd@gmail.com>
 * initialise the headers of MSG_BLACKHOLE objects properly
Mon Mar 29 15:45:21 GMT Daylight Time 2010  Simon Marlow <marlowsd@gmail.com>
 * Move a thread to the front of the run queue when another thread blocks on it

A small example of it going wrong, with debugging on in GHC.IO.FD, looks like this:

$ ghc-stage1.exe --make openFile004 -fforce-recomp -Wall
$ ./openFile004 2>&1 | head -10
readBuf fd=3 buf512(0-0)
IG 1 512
after: buf512(0-5948896)
Segmentation fault/access violation in generated code

where this is expected:

$ ./openFile004 2>&1 | head -10
readBuf fd=3 buf512(0-0)
IG 1 512
after: buf512(0-13)
readBuf fd=3 buf512(0-0)
IG 1 512
after: buf512(0-0)
writeBuf fd=1 buf512(0-4)
12

Code is:

import System.IO

main :: IO ()
main = do
  h <- openFile "openFile004.out" ReadMode
  let loop :: Int -> IO ()
      loop n = do
        b <- hIsEOF h
        if b then print n
             else do _ <- hGetChar h
                     -- putChar c
                     loop (n + 1)
  loop 0

$ hexdump -C openFile004.out
00000000  68 65 6c 6c 6f 20 77 6f  72 6c 64 0d 0a           |hello world..|
0000000d

[simonmar]

Thanks Ian for narrowing down the crash. I'm looking into it.

[simonmar]

Fixed:

Tue Apr 20 13:21:25 BST 2010  Simon Marlow <marlowsd@gmail.com>
  * Fix crash in non-threaded RTS on Windows
  The tso->block_info field is now overwritten by pushOnRunQueue(), but
  stg_block_async_info was assuming that it still held a pointer to the
  StgAsyncIOResult.  We must therefore save this value somewhere safe
  before putting the TSO on the run queue.