[GHC] #14915: T2783 fails with the threaded1 way

[GHC]

#14915: T2783 fails with the threaded1 way
-------------------------------------+-------------------------------------
        Reporter:  alpmestan         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:  8.5
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  Runtime crash     |            Test Case:  T2783
      Blocked By:                    |             Blocking:
 Related Tickets:  #15241            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by osa1):

 * cc: simonmar (added)


Comment:

 It seems to me that the assertion is wrong. Here's the stack of the TSO
 when we
 call `threadPaused()`: (the full stack is larger, only showing the
 relevant
 part here)

 {{{
 >>> call printStack(tso->stackobj)
 RET_FUN (0x7af578) (type=5) <------------------------ 0x42000060a0
    stk[91] (0x42000060b0) = 0x7af578
 stg_ap_pp_info <------------------------------------- 0x42000060c0
    stk[88] (0x42000060c8) = 0x42000084f9
    stk[87] (0x42000060d0) = 0x4200008428
 NORMAL_UPDATE_FRAME(0x71da08,0x4200008428) <--------- 0x42000060d8
 RET_SMALL (0x668d50) <------------------------------- 0x42000060e8
    stk[83] (0x42000060f0) = 0x42000084e9
    stk[82] (0x42000060f8) = 0x4200008428
 NORMAL_UPDATE_FRAME(0x71da08,0x4200008428) <--------- 0x4200006100
 assertion fails here
 ...
 }}}


 So we have multiple update frames in this stack that updates same closure
 at
 0x4200008428 which is originally a THUNK:

 {{{
 >>> call printClosure(0x4200008428)
 THUNK(0x404cf8)
 }}}

 which becomes a BLACKHOLE as expected when we see it the first time in
 stack
 frame at 0x42000060d8. Then two iterations later we see the same closure
 in the
 update frame at 0x4200006100 but the assertion assumes that it's either
 not a
 BLACKHOLE or if it is then it's BLACKHOLEd by another thread. It seems to
 me
 that this assertion gives a false positive when we have a `<<loop>>` and
 should
 be updated (removed?).

 simonmar, am I right that this case can legitimately happen when we have a
 loop?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14915#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler