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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
