[GHC] #15508: concprog001 fails with various errors

[GHC]

#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:

 {{{
 >>> bt
 #0  __GI_raise (sig=sig at 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,
 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)
 }}}

 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:

 {{{
 >>> 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
 <stg_IND_info>) 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>,
 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