> At the moment I'm trying to hunt down a probably GC-related bug in
> ghc-4.03 from CVS, but I'm not totally sure if this is the real reason
> for some extremely strange segmentation faults. So, in an act of total
> despair, I've tried to build a ghc with the flags -DDEBUG -optc-DDEBUG
> and bootstrap itself. Some observations:
>
> * There are some small bugs in fptools/ghc/includes/PrimOps.h,
> patch appended, though I'm not very sure about changing
> ARR_PTRS_info to MUT_ARR_PTRS_FROZEN_info.
Ok - we don't generally compile .hc files with -DDEBUG.
> * In the bootstrapping phase there are about 100 warnings like
>
> WARNING: file rename/RnIfaces.lhs line 321 Type!Kind{-r3Z8,j-}
Yep, Simon is in the process of looking at this. It's mostly harmless.
> * During compilation of my program (with -DDEBUG -optc-DDEBUG)
> renameSourceCode gives a lot of warnings. Some examples:
>
> Note: renameSourceCode found warnings
> GL_Misc.hs:65: Warning: Defined but not used:
> cmp_eq{-r4Gf-}
>
> (This seems to happen for every constructor with an associated
> "deriving (Eq,Ord)")
>
> Note: renameSourceCode found warnings
> <compiler-generated-code>:
> Warning: definition but no type signature for
> `con2tag_Bufferzh{-r4oB-}'
>
> (For every type with "deriving (Eq,Ord)")
>
> Note: renameSourceCode found warnings
> Foo.hs:58: Warning: Defined but not used: a{-r5Bt-}
>
> (This is somehow "deriving Show"-related.)
Hmm, we need to get the renamer to ignore warnings for automatically
generated code. Noted.
> * All the barfs handling unexpected cases in fptools/ghc/rts should
> print the value which the enclosing switch doesn't handle. This
> would make debugging easier...
Well, if something goes wrong you probably need to be in gdb to track it
down anyway, so I never bothered making these messages more informative.
> The reason for all this hassle is that some of my HOpenGL
> examples raise
> a segmentation fault from time to time. Changing the source
> code *very*
> slightly, using a two-space collector (+RTS -G1), using +RTS
> -Z, varying
> the stack and/or heap sizes, etc. result in a large variety of runtime
> errors:
>
> Segmentation Fault
> ASSERTION FAILED: file GC.c, line 2779
> relocate_TSO
> scavenge_mut_list: strange object?
>
> My current suspects are mutable byte arrays which survive a
> few GCs, but
> this is currently only a wild guess.
It does sound suspiciously like a GC problem. If you find a repeatable
example, please send us a copy...
Cheers,
Simon
