Building ghc with DEBUG: ASSERTION FAILED: file Capability.h, line 297

[Simon Marlow]

Ian Lynagh wrote:
> On Sun, Jan 11, 2009 at 08:21:36PM +0100, Matthias Kilian wrote:
>> [...]
>>> If you can get this just by compiling Haddock with -debug, then it could 
>>> be a bug.  In our nightly builds we do turn on -debug for the stage2 build 
>>> and hence compile all of stage 3 with the debugging-enabled stage 2, 
>>> though.
>> It still happens, with only Haddock built with -debug
> 
> I can reproduce this. I haven't fixed it, but what's going wrong is that
> when shutting down we're setting my_task to NULL:
> 
> Old value = (Task *) 0x3befe40
> New value = (Task *) 0x0
> setMyTask (task=0x0) at Task.h:263
> 263     }
> (gdb) bt
> #0  setMyTask (task=0x0) at Task.h:263
> #1  0x000000000175dd03 in boundTaskExiting (task=0x3befe40) at Task.c:187
> #2  0x0000000001753d5a in rts_unlock (cap=0x1c66180) at RtsAPI.c:657
> #3  0x00000000017513a1 in real_main () at Main.c:114
> #4  0x0000000001751459 in main (argc=34, argv=0x7fff8c80a5f8) at Main.c:156
> 
> and then when garbage collecting we're checking that it's equal to
> cap->running_task (which is equal to its old value, 0x3befe40) at
> Capability.h line 299:
> 
>     ASSERT(cap->running_task == myTask());
> 
> #0  0x00007f00833e7ef5 in raise () from /lib/libc.so.6
> #1  0x00007f00833e9413 in abort () from /lib/libc.so.6
> #2  0x0000000001755cc0 in rtsFatalInternalErrorFn (
>     s=0x1849f50 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fff8c809ff0)
>     at RtsMessages.c:164
> #3  0x0000000001755884 in barf (
>     s=0x1849f50 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40
> #4  0x00000000017558de in _assertFail (filename=0x184d38e "./Capability.h", 
>     linenum=304) at RtsMessages.c:55
> #5  0x000000000176b251 in recordMutableCap (p=0x7f0082b833f0, cap=0x1c66180, 
>     gen=1) at ./Capability.h:304
> #6  0x000000000176b34c in setTSOLink (cap=0x1c66180, tso=0x7f0082b833f0, 
>     target=0x7f008308a068) at sm/Storage.c:880
> #7  0x0000000001758552 in appendToRunQueue (cap=0x1c66180, tso=0x7f008308a068)
>     at Schedule.h:188
> #8  0x0000000001759e19 in scheduleThread (cap=0x1c66180, tso=0x7f008308a068)
>     at Schedule.c:2038
> #9  0x000000000175f8fe in scheduleFinalizers (cap=0x1c66180, 
>     list=0x7f008274c030) at Weak.c:145
> #10 0x0000000001763501 in GarbageCollect (force_major_gc=rtsFalse, gc_type=0, 
>     cap=0x1c66180) at sm/GC.c:737
> #11 0x0000000001759772 in scheduleDoGC (cap=0x1c66180, task=0x0, 
>     force_major=rtsFalse) at Schedule.c:1631
> #12 0x000000000175a067 in exitScheduler (wait_foreign=rtsFalse)
>     at Schedule.c:2220
> #13 0x0000000001756111 in hs_exit_ (wait_foreign=rtsFalse) at RtsStartup.c:410
> #14 0x000000000175624e in shutdownHaskellAndExit (n=0) at RtsStartup.c:557
> #15 0x0000000001751422 in real_main () at Main.c:144
> #16 0x0000000001751459 in main (argc=34, argv=0x7fff8c80a5f8) at Main.c:156
> 
> I'd guess the reason we don't see it in GHC builds is that it only goes
> wrong with the non-threaded RTS.

I believe I've fixed this now.  Thanks for looking into it!

Cheers,
	Simon