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

#8316: GHCi debugger panics 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 Ben Gamari ): In [changeset:"45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce/ghc" 45ed461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce" Fix BLACKHOLE inspection in RtClosureInspect When inspecing a BLACKHOLE if the BLACKHOLE points to a TSO or a BLOCKING_QUEUE we should return a suspension to the BLACKHOLE itself (instead of returning a suspension to the indirectee). The reason is because in the debugger when we want to evaluate this term we need to enter the BLACKHOLE and not to the TSO or BLOCKING_QUEUE. See the runtime panic caused by this in #8316. Note that while with this patch we do the right thing to evaluate thunks in GHCi, evaluating thunks that are owned by the evaluator thread in a breakpoint will cause a deadlock as we don't release the breakMVar, which is what blocks the evaluator thread from continuing with evaluation. So the GHCi thread will enter the BLACKHOLE, but owner of the BLACKHOLE is also blocked. Reviewers: simonmar, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #8316 Differential Revision: https://phabricator.haskell.org/D5179 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler