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