There are two possible avenues to proceed along. The first is to figure out from the crashing stage2 compiler what is going wrong to cause the segfault. But I think this compiler was created in a broken state. The "unknown relocation error 4" from the new 'ld' in 10.5 means it sees but cannot handle scattered PPC_RELOC_HI16 segments. I am guessing that the stage2 compiler is linked wrong, which may be why it ends up with a bad address and the error:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x4082000c
I do not think I know enough about compilers and linkers to write a good bug report to Apple about the fact that 'ld' seems (to me) to write scattered PPC_RELOC_HI16 segments which it cannot read and recognize. Corey O'Conner : you are debugging ld as well. Does the 'ld' code look broken to you (as detailed in my earlier reply to your message) ? Cheers, Chris Simon Marlow wrote:
The crash is in Haskell code, so the C backtrace is not to be trusted. Actually in this case it looks correct up to schedule(), and the uppermost frame is probably correct - the crash was really in stg_ap_p_fast, but in between is garbage (base_GHCziIOBase_noDuplicate_info).
Looks like you're making good progress here, though! Working backwards from the crash and try to find out where the erroneous memory access originated is the next step. The wiki page has some useful tips:
http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes
Cheers, Simon