#8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I can confirm this behavior on MacOS 10.8.4 (x86_64) and with HEAD as of 27 Aug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a61e717fcff9108337b1d35783ea3afbf591d3c6/ghc" a61e717f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a61e717fcff9108337b1d35783ea3afbf591d3c6" testsuite: Add testcase for #8316 This is still broken but really out to be fixed. At least know we'll know if someone fixes it inadvertently. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1682 GHC Trac Issues: #8316 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Confirmed on 8.4.1 and HEAD (8.5.20180308). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I've been looking into this, here's what I found out so far: - Because we start evaluating `foo` before hitting the breakpoint, by the time the we return to the GHCi prompt `foo` points to a blackhole. - Once we stop at the breakpoint we do `:print foo`, `pprintClosureCommand` calls `bindSuspensions` with the id `foo`. - `bindSuspensions` invents a new name `_t1` and binds it to the thunk that is `foo`, via `RtClosureInspect.cvObtainTerm`. - `cvObtainTerm` looks at the heap object pointed to by `foo`, which is a blackhole, and follows the indirectee pointer. It turns out the indirectee is a TSO object. At this point `_t1` becomes bound to a TSO object, and evaluating it (e.g. with `print _t1`) causes this crash because TSO objects can't be entered. I tried modifying `cvObtainTerm` so that it doesn't follow the indirectee pointer when it sees a blackhole. That way we bind `_t1` to 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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: Nolan 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Nolan): * owner: (none) => Nolan Old description:

The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ())

foo :: [Int] foo = [1..] }}}

Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}}

and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}}

results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 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-ghci }}}

New description: The file Test.hs has following definition: {{{ foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and 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.hs:2:7-11] *Main> :print foo foo = (_t1::[Int]) [main.hs:2:7-11] [main.hs:2:7-11] *Main> _t1 }}} results in this segault: {{{ <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-ghci }}} -- Comment: I simplified example. whnf function is not required to trigger this bug. You can also notice that context of execution (i.e. [main.hs:2:7-11]) prints twice which looks like a bug and probably deserves a ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thanks for the simplification. Which GHC version did you use to try this? I don't see the prompt printed twice on 8.4.1 and HEAD> -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thanks, it turns out I have to use the default prompt to reproduce. Reported as #14973. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Old description:

The file Test.hs has following definition: {{{ foo :: [Int] foo = [1..] }}}

Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}}

and 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.hs:2:7-11] *Main> :print foo foo = (_t1::[Int]) [main.hs:2:7-11] [main.hs:2:7-11] *Main> _t1 }}}

results in this segault: {{{ <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-ghci }}}

New description: The file Test.hs has following definition: {{{ foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and 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> _t1 }}} results in this segault: {{{ <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-ghci }}} -- Comment (by Nolan): Bug with context printed twice was fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D4535 => Phab:D4535, Phab:D5179 Comment: I submitted a diff. As expected, it causes a deadlock in the reproducer. Simon, any ideas on how to fix the deadlock? Would it be possible to resume the evaluator thread (by updating `breakMVar`) before entering a BLACKHOLE? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#8316: GHCi debugger panics 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 Ben Gamari ): In [changeset:"45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce/ghc" 45ed461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce" 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 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | 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): Should this really be closed? I thought we want to do implement rest of the ideas in comment:19 too. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: GHCi | Version: 7.6.3 Resolution: | Keywords: debugger, | newcomer 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 -------------------------------------+------------------------------------- Changes (by osa1): * keywords: debugger => debugger, newcomer * priority: high => normal * milestone: 8.8.1 => ⊥ Comment: The panic has been fixed, rest of comment:19 still need to be implemented, but they're not as urgent. Removing the milestone and marking the ticket as 'newcomer'. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8316#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler