GHCi debugger panics when trying force a certain variable
The file Test.hs has following definition:
foo :: [Int]
foo = [1..]Calling ghci as:
ghci Test.hs -ignore-dot-ghciand bebugging foo like this:
*Main> :break foo
Breakpoint 0 activated at main.hs:2:7-11
*Main> foo
Stopped in Main.foo, main.hs:2:7-11
_result :: [Int] = _
[main.hs:2:7-11] *Main> :print foo
foo = (_t1::[Int])
[main.hs:2:7-11] *Main> _t1results in this panic:
<interactive>: internal error: TSO object entered!
(GHC version 8.5.20180302 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghciActivity
added GHCi Tbug Trac import labels
Attached file
Test.hs($909).The Test.hs file containing the definitions.
mentioned in commit a61e717f
mentioned in issue #12383
added debugger label
I've been looking into this, here's what I found out so far:
-
Because we start evaluating
foobefore hitting the breakpoint, by the time the we return to the GHCi promptfoopoints to a blackhole. -
Once we stop at the breakpoint we do
:print foo,pprintClosureCommandcallsbindSuspensionswith the idfoo. -
bindSuspensionsinvents a new name_t1and binds it to the thunk that isfoo, viaRtClosureInspect.cvObtainTerm. -
cvObtainTermlooks at the heap object pointed to byfoo, which is a blackhole, and follows the indirectee pointer. It turns out the indirectee is a TSO object. At this point_t1becomes bound to a TSO object, and evaluating it (e.g. withprint _t1) causes this crash because TSO objects can't be entered.
I tried modifying
cvObtainTermso that it doesn't follow the indirectee pointer when it sees a blackhole. That way we bind_t1to 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?
-
Simon, I implemented changes in
cvObtainTermas discussed yesterday, but I'm still getting "TSO object entered" errors.Previously
cvObtainTermfollwed indirectee's of BLACKHOLEs no matter what.With my changes I only follow the indirectees when they're not TSO or BLOCKING_QUEUE. Somehow with this I still get "TSO object entered".
If I don't follow BLACKHOLE indirectees at all (and bind a BLACKHOLE to
_t1in this reproducer) then I get a deadlock as expected. Do you have any ideas on why this may be happening?assigned to @trac-Nolan
mentioned in issue #14973 (closed)
Thanks, it turns out I have to use the default prompt to reproduce. Reported as #14973 (closed).
I created a differential with an implementation of the idea in ticket:8316#comment:150788. The patch seems to do the right thing but there's probably another bug in somewhere else so I'm still getting "TSO entered" errors.
Trac metadata
Trac field Value Differential revisions - → D4535 mentioned in issue #15010
Ah, looking at this ticket again, I can see what I missed last time (in D4535).
The problem is D4535 does not have any effect because TSO and BLOCKING_QUEUE are already not handled by
cvObtainTerm.goandcvObtainTermreturns aSuspensionwhen it finds one of those objects. So even if we follow a BLACKHOLE that points to a TSO we return aSuspension. In D4535 we returnedSuspensionslightly 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
Suspensionwith the BLACKHOLE itself as thehval(currently:hvalis 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.I don't see a good way to solve this. The thread that is evaluiating
foois stopped at a breakpoint - that's what the user asked for, so it's not entirely surprising that if they evaluate something that requiresfoothen it deadlocks.What would we like to happen? I can think of a couple of alternatives:
- *1. Just make it work**
Should it automatically continue evaluation of
foo? How would you know when to do that? Evaluating a BLACKHOLE doesn't necessarily mean that we're about to deadlock, we might be evaluating something that another thread is evaluating. As soon as we release thebreakMVarthe thread will continue evaluatingfoo, but I don't know of a way to tell whether/when we should do that.Perhaps instead of the MVar, a breakpoint should be an asynchronous exception so that we end up with a thunk that we could poke to continue evaluation? That would make this work, but it would mean a big change to the way breakpoints work and I'm not sure whether it would run into other problems. One potential problem is that it's a lot more expensive than the current breakpoint mechanism, so
:tracewouldn't work so well.- *2. Make it an error of some kind**
e.g.
[main.hs:2:7-11] *Main> _t1 *** Exception: blocked on breakpoint 1The question is how to achieve that. Perhaps we periodically monitor the thread we just created to do the evaluation and check whether it's blocked on a blackhole, and then compare the owner of the blackhole it is blocked on against all the threads we know are currently at breakpoints? That could possibly work, but it's tricky to implement.
Here's another example that deadlocks even with GHC 8.6:
foo = 0 : bar bar = 1 : fooin GHCi:
GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help :Loaded GHCi configuration from /home/omer/rcbackup/.ghci [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, one module loaded. λ:1> :break foo Breakpoint 0 activated at test.hs:1:7-13 λ:2> foo Stopped in Main.foo, test.hs:1:7-13 _result :: [Integer] = _ [test.hs:1:7-13] λ:3> :print bar bar = (_t1::[Integer]) [test.hs:1:7-13] λ:4> _t1 [1The reason why we don't get "TSO entered" here is because _t1 stands for
bar, andbaritself is not locked by the evaluator thread. Instead an object inbar's payload is owned.I think this shows that even if we could somehow release the MVar in the original reproducer there will be deadlocks.
I think we should:
- Merge the patch. We should never enter a TSO or BLOCKING_QUEUE.
- Document this behavior in the user manual
- Disallow evaluating BLACKHOLEs in GHCi
The last step would fix the original reproducer, but my example above will still deadlock and that's what you get for having lazy evaluation.
mentioned in commit 45ed4619
changed milestone to %8.8.1
Should this really be closed? I thought we want to do implement rest of the ideas in ticket:8316#comment:160624 too.
I left a comment drawing attention to this on the D5179 before merging but yes, you are right, we should wait to close this until all of these tasks are done.
Trac metadata
Trac field Value Resolution ResolvedFixed → Unresolved changed milestone to %⊥
The panic has been fixed, rest of ticket:8316#comment:160624 still need to be implemented, but they're not as urgent. Removing the milestone and marking the ticket as 'newcomer'.
Trac metadata
Trac field Value Priority high → normal added broken test label
added Pnormal label
