bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f7bf5709801 in __GI_abort () at abort.c:79 #2 0x00000000007313b5 in rtsFatalInternalErrorFn (s=0x79fd90 "ASSERTION FAILED: file %s, line %u\n", ap=0x7ffe92feb8b8) at rts/RtsMessages.c:186 #3 0x0000000000730fd9 in barf (s=0x79fd90 "ASSERTION FAILED: file %s,
#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D5051 => Phab:D5051 (reverted), Phab:D5165 Comment: Fixing one bug reveals others. I'm currently getting this {{{ Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 296 (GHC version 8.7.20180919 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The stack trace: {{{ line %u\n") at rts/RtsMessages.c:48 #4 0x000000000073103e in _assertFail (filename=0x7a55f0 "rts/sm/Sanity.c", linenum=296) at rts/RtsMessages.c:63 #5 0x0000000000751be3 in checkClosure (p=0x42008e45e0) at rts/sm/Sanity.c:295 #6 0x00000000007521b0 in checkHeapChain (bd=0x4200803900) at rts/sm/Sanity.c:450 #7 0x0000000000752bf1 in checkGeneration (gen=0x10ec408, after_major_gc=false) at rts/sm/Sanity.c:745 #8 0x0000000000752cc1 in checkFullHeap (after_major_gc=false) at rts/sm/Sanity.c:764 #9 0x0000000000752d3b in checkSanity (after_gc=false, major_gc=false) at rts/sm/Sanity.c:773 #10 0x000000000074e99b in GarbageCollect (collect_gen=0, do_heap_census=false, gc_type=0, cap=0x90e1c0 <MainCapability>, idle_cap=0x0) at rts/sm/GC.c:320 #11 0x0000000000734141 in scheduleDoGC (pcap=0x7ffe92febcb0, task=0x10fdd50, force_major=false) at rts/Schedule.c:1800 #12 0x0000000000733619 in schedule (initialCapability=0x90e1c0 <MainCapability>, task=0x10fdd50) at rts/Schedule.c:546 #13 0x0000000000734b13 in scheduleWaitThread (tso=0x4200105388, ret=0x0, pcap=0x7ffe92febdb0) at rts/Schedule.c:2537 #14 0x0000000000743205 in rts_evalLazyIO (cap=0x7ffe92febdb0, p=0x7d5710, ret=0x0) at rts/RtsAPI.c:530 #15 0x000000000074394c in hs_main (argc=1, argv=0x7ffe92febfa8, main_closure=0x7d5710, rts_config=...) at rts/RtsMain.c:72 #16 0x000000000042fd6e in main () }}} The assertion that fails: {{{ ASSERT(bq->queue == (MessageBlackHole*)END_TSO_QUEUE || bq->queue->header.info == &stg_MSG_BLACKHOLE_info); }}} bq->queue is actually an IND: {{{
print bq->queue $1 = (struct MessageBlackHole_ *) 0x42001df098 call printClosure(bq->queue) IND(0x42001de350) }}}
watch ((StgBlockingQueue *) 0x42008e45e0)->queue->header.info Hardware watchpoint 1: ((StgBlockingQueue *) 0x42008e45e0)->queue->header.info reverse-continue bt #0 0x00000000007406a0 in SET_INFO (c=0x42001df098, info=0x763e08
) at includes/rts/storage/ClosureMacros.h:49 #1 0x0000000000740dfe in throwToMsg (cap=0x90e1c0 <MainCapability>, msg=0x42000cc180) at rts/RaiseAsync.c:412 #2 0x0000000000740905 in throwTo (cap=0x90e1c0 <MainCapability>,
There's a note about this in Evac.c: {{{ // Note [BLACKHOLE pointing to IND] // // BLOCKING_QUEUE can be overwritten by IND (see // wakeBlockingQueue()). However, when this happens we must // be updating the BLACKHOLE, so the BLACKHOLE's indirectee // should now point to the value. // // The mutator might observe an inconsistent state, because // the writes are happening in another thread, so it's // possible for the mutator to follow an indirectee and find // an IND. But this should never happen in the GC, because // the mutators are all stopped and the writes have // completed. }}} It seems like this currently does not hold. We're in GC and observe that a BLOCKING_QUEUE is actually an IND. Adding watchpoint to see when it became an IND: {{{ source=0x420040e438, target=0x42008bcc40, exception=0x7df158) at rts/RaiseAsync.c:213 #3 0x00000000007613c2 in stg_killThreadzh () #4 0x0000000000000000 in ?? () }}} I'm not sure when this object is supposed to become a BLACKHOLE (or END_TSO_QUEUE) again. Simon, any ideas? I'm also confused why a note about blackholes talk about BLOCKING_QUEUE... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15508#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler