#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