[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 simonmar):

 I don't see a good way to solve this. The thread that is evaluiating `foo`
 is stopped at a breakpoint - that's what the user asked for, so it's not
 entirely surprising that if they evaluate something that requires `foo`
 then it deadlocks.

 What would we like to happen? I can think of a couple of alternatives:

 **1. Just make it work**

 Should it automatically continue evaluation of `foo`? How would you know
 when to do that? Evaluating a BLACKHOLE doesn't necessarily mean that
 we're about to deadlock, we might be evaluating something that another
 thread is evaluating. As soon as we release the `breakMVar` the thread
 will continue evaluating `foo`, but I don't know of a way to tell
 whether/when we should do that.

 Perhaps instead of the MVar, a breakpoint should be an asynchronous
 exception so that we end up with a thunk that we could poke to continue
 evaluation? That would make this work, but it would mean a big change to
 the way breakpoints work and I'm not sure whether it would run into other
 problems. One potential problem is that it's a lot more expensive than the
 current breakpoint mechanism, so `:trace` wouldn't work so well.

 **2. Make it an error of some kind**

 e.g.

 {{{
 [main.hs:2:7-11] *Main> _t1
 *** Exception: blocked on breakpoint 1
 }}}

 The question is how to achieve that. Perhaps we periodically monitor the
 thread we just created to do the evaluation and check whether it's blocked
 on a blackhole, and then compare the owner of the blackhole it is blocked
 on against all the threads we know are currently at breakpoints? That
 could possibly work, but it's tricky to implement.

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