#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: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, looking at this ticket again, I can see what I missed last time (in Phab:D4535). The problem is Phab:D4535 does not have any effect because TSO and BLOCKING_QUEUE are already not handled by `cvObtainTerm.go` and `cvObtainTerm` returns a `Suspension` when it finds one of those objects. So even if we follow a BLACKHOLE that points to a TSO we return a `Suspension`. In Phab:D4535 we returned `Suspension` slightly earlier (before following the indirectee), but the value we returned was identical to the value we returned without the patch. What we should do is if we see a BLACKHOLE pointing to an TSO or BLOCKING_QUEUE we should return a `Suspension` with the BLACKHOLE itself as the `hval` (currently: `hval` is the indirectee). However I suspect entering the BLACKHOLE will result in a deadlock because the thread that's supposed to evaluate the expression (i.e. the owner) is blocked on an MVar (the breakpoint MVar passed to `GHCi.Run.withBreakAction`) and when we enter the BLACKHOLE our thread gets parked, to be unparked by the owner of the BLACKHOLE, which never happens as we don't update the MVar before entering the BLACKHOLE. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler