[GHC] #8316: GHCi debugger segfaults when trying force a certain variable

[GHC]

#8316: GHCi debugger segfaults when trying force a certain variable
-------------------------------------+-------------------------------------
        Reporter:  guest             |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:
       Component:  GHCi              |              Version:  7.6.3
      Resolution:                    |             Keywords:  debugger
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  GHCi crash        |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4535,
       Wiki Page:                    |  Phab:D5179
-------------------------------------+-------------------------------------

Comment (by osa1):

 Here's another example that deadlocks even with GHC 8.6:

 {{{
 foo = 0 : bar
 bar = 1 : foo
 }}}

 in GHCi:

 {{{
 GHCi, version 8.6.1: http://www.haskell.org/ghc/  :? for help
 :Loaded GHCi configuration from /home/omer/rcbackup/.ghci
 [1 of 1] Compiling Main             ( test.hs, interpreted )
 Ok, one module loaded.
 λ:1> :break foo
 Breakpoint 0 activated at test.hs:1:7-13
 λ:2> foo
 Stopped in Main.foo, test.hs:1:7-13
 _result :: [Integer] = _
 [test.hs:1:7-13] λ:3> :print bar
 bar = (_t1::[Integer])
 [test.hs:1:7-13] λ:4> _t1
 [1
 }}}

 The reason why we don't get "TSO entered" here is because _t1 stands for
 `bar`, and `bar` itself is not locked by the evaluator thread. Instead an
 object in `bar`'s payload is owned.

 I think this shows that even if we could somehow release the MVar in the
 original reproducer there will be deadlocks.

 I think we should:

 - Merge the patch. We should never enter a TSO or BLOCKING_QUEUE.
 - Document this behavior in the user manual
 - Disallow evaluating BLACKHOLEs in GHCi

 The last step would fix the original reproducer, but my example above will
 still deadlock and that's what you get for having lazy evaluation.

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