GHC 6.8.1 on powerpc OS X 10.5

[Simon Marlow]

Chris Kuklewicz wrote:

>> (gdb) run --make /tmp/t.hs -o /tmp/t
>> Starting program:
> /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compiler/stage2/ghc-6.8.1
> --make /tmp/t.hs -o /tmp/t
>> Reading symbols for shared libraries +..+... done
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x4082000c
>> 0x012ba9c8 in stg_ap_p_fast ()
> 
>> (gdb) bt
>> #0  0x012ba9c8 in stg_ap_p_fast ()
>> #1  0x010d79ec in base_GHCziIOBase_noDuplicate_info ()
>> #2  0x01290e58 in schedule (initialCapability=0x41810070, task=0x38600000) at
> Schedule.c:621
>> #3  0x012933c8 in scheduleWaitThread (tso=0x2680000, ret=0x0, cap=0x14c4318)
> at Schedule.c:2500
>> #4  0x01285040 in rts_evalIO (cap=0x14c4318, p=0x13f40b4, ret=0x0) at RtsAPI.c:476
>> #5  0x0129d310 in ioManagerStart () at posix/Signals.c:151
>> #6  0x0128841c in hs_init (argc=0xbffff4a8, argv=0xbffff4ac) at RtsStartup.c:279
>> #7  0x01288464 in startupHaskell (argc=5, argv=0xbffff594, init_root=0x113cc
> <__stginit_ZCMain>) at RtsStartup.c:290
>> #8  0x0127ebbc in real_main () at Main.c:57
>> #9  0x0127ed1c in main (argc=5, argv=0xbffff594) at Main.c:153

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