Fix BLACKHOLE inspection in RtClosureInspect
authorÖmer Sinan Ağacan <omeragacan@gmail.com>
Mon, 15 Oct 2018 17:53:21 +0000 (13:53 -0400)
committerBen Gamari <ben@smart-cactus.org>
Mon, 15 Oct 2018 23:24:17 +0000 (19:24 -0400)
commit45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce
treea127226850802a0aad71d2e4d3690e5e4502d57c
parent8306141397d6e47a169dbe4b7ff1b3319a502aa7
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
compiler/ghci/RtClosureInspect.hs