debug_p RTS is buggy (debugging and profiled)

I think some of the sanity assertions that debugging enables are not being adjusted adequately when profiling is turned on. We probably never caught this because we don't build debug_p by default. I see some worse problems under some more complicated test-cases but lets go with the simple case first!

fib :: Integer -> Integer
fib 0 = 1
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

main = print (fib 25)

built as

/srv/code/ghc-build-tick/inplace/bin/ghc-stage2 -fforce-recomp -fprof-drop -prof -debug --make dp.hs -O -rtsopts

run as

ezyang@javelin:~/Dev/haskell$ ./dp +RTS -DS
cap 0: initialised
dp: internal error: checkClosure: found EVACUATED closure 0
    (GHC version 7.7 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)

Here is the GDB backtrace:

Program received signal SIGABRT, Aborted.
0x00007ffff6ec4425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6ec4425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6ec7b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000000000a552b7 in rtsFatalInternalErrorFn (s=0xba5038 "checkClosure: found EVACUATED closure %d", ap=0x7fffffffd4d8) at rts/RtsMessages.c:170
#3  0x0000000000a54eef in barf (s=0xba5038 "checkClosure: found EVACUATED closure %d") at rts/RtsMessages.c:42
#4  0x0000000000a6a368 in checkClosure (p=0x7ffff64fe988) at rts/sm/Sanity.c:237
#5  0x0000000000a6aa54 in checkHeapChain (bd=0x7ffff6403f80) at rts/sm/Sanity.c:450
#6  0x0000000000a6b2f1 in checkGeneration (gen=0xe7a0e0, after_major_gc=rtsFalse) at rts/sm/Sanity.c:706
#7  0x0000000000a6b3bc in checkFullHeap (after_major_gc=rtsFalse) at rts/sm/Sanity.c:724
#8  0x0000000000a6b42b in checkSanity (after_gc=rtsFalse, major_gc=rtsFalse) at rts/sm/Sanity.c:733
#9  0x0000000000a662bb in GarbageCollect (collect_gen=0, do_heap_census=rtsFalse, gc_type=0, cap=0xe6b680 <MainCapability>) at rts/sm/GC.c:298
#10 0x0000000000a579dd in scheduleDoGC (pcap=0x7fffffffd860, task=0xe8ccf0, force_major=rtsFalse) at rts/Schedule.c:1651
#11 0x0000000000a56f92 in schedule (initialCapability=0xe6b680 <MainCapability>, task=0xe8ccf0) at rts/Schedule.c:553
#12 0x0000000000a582b6 in scheduleWaitThread (tso=0x7ffff6405378, ret=0x0, pcap=0x7fffffffd930) at rts/Schedule.c:2359
#13 0x0000000000a98156 in rts_evalLazyIO (cap=0x7fffffffd930, p=0xdc2840, ret=0x0) at rts/RtsAPI.c:497
#14 0x0000000000a54d5b in real_main () at rts/RtsMain.c:63
#15 0x0000000000a54e4a in hs_main (argc=3, argv=0x7fffffffda98, main_closure=0xdc2840, rts_config=...) at rts/RtsMain.c:114
#16 0x0000000000404bb3 in main ()

and here is the heap in the vicinity of the problem:

(gdb) pmem (p-8) 64
0x7ffff64fe9a8:	0x7ffff6405369
0x7ffff64fe9a0:	0x0
0x7ffff64fe998:	0xdc3650
0x7ffff64fe990:	0xa79818 <stg_BLACKHOLE_info>
0x7ffff64fe988:	0x7ffff64fe909
0x7ffff64fe980:	0x7ffff6405349
0x7ffff64fe978:	0x0
0x7ffff64fe970:	0xdc3650
0x7ffff64fe968:	0xa79818 <stg_BLACKHOLE_info>
0x7ffff64fe960:	0x7ffff6405201
0x7ffff64fe958:	0x0
0x7ffff64fe950:	0xdc3650
0x7ffff64fe948:	0xa79818 <stg_BLACKHOLE_info>