
#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 osa1): Here's another example that deadlocks even with GHC 8.6: {{{ foo = 0 : bar bar = 1 : foo }}} in 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 [1 }}} The reason why we don't get "TSO entered" here is because _t1 stands for `bar`, and `bar` itself is not locked by the evaluator thread. Instead an object in `bar`'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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler