
#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: | Phab:D5179 -------------------------------------+------------------------------------- Comment (by simonmar): I don't see a good way to solve this. The thread that is evaluiating `foo` is stopped at a breakpoint - that's what the user asked for, so it's not entirely surprising that if they evaluate something that requires `foo` then 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 the `breakMVar` the thread will continue evaluating `foo`, 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 `:trace` wouldn'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 1 }}} The 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler