[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):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 I've been looking into this, here's what I found out so far:

 - Because we start evaluating `foo` before hitting the breakpoint, by the
 time the we return to the GHCi prompt `foo` points to a blackhole.

 - Once we stop at the breakpoint we do `:print foo`,
 `pprintClosureCommand` calls `bindSuspensions` with the id `foo`.

 - `bindSuspensions` invents a new name `_t1` and binds it to the thunk
 that is `foo`, via `RtClosureInspect.cvObtainTerm`.

 - `cvObtainTerm` looks at the heap object pointed to by `foo`, which is a
 blackhole, and follows the indirectee pointer. It turns out the indirectee
 is a TSO object. At this point `_t1` becomes bound to a TSO object, and
 evaluating it (e.g. with `print _t1`) causes this crash because TSO
 objects can't be entered.

 I tried modifying `cvObtainTerm` so that it doesn't follow the indirectee
 pointer when it sees a blackhole. That way we bind `_t1` to the blackhole
 object instead of the TSO object pointed by the indirectee field, but that
 caused a deadlock in the scheduler. I don't understand why yet.

 simonmar, could you advise? Does the story make sense so far?

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