[GHC] #10052: Panic (something to do with floatExpr?)
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by edsko): Call the driver with {{{ # ./T145 ./T145-input.hs -XScopedTypeVariables -O }}} to cause the panic (no panic happens if you don't specify -O). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Peter Wortman says: We are clearly trying to float past a breakpoint here, which is simply impossible. Pretty sure this would have been a panic before my changes too (it would have tried to "mkNoCount" the breakpoint). Guess I was wrong reading a "breakpoints don't appear here" invariant out of that... The quick fix would be to drop all floats in-place: {{{ -- scoped, counting and unsplittable, can't be floated through | otherwise = floatBody tOP_LEVEL expr }}} This fixes the panic, but is a bit awkward. Probably better to change `SetLevels`? Not a piece of code I'm very familiar with... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Peter says (further)
Why do you say "we are clearly trying to float past a breakpoint"? Why is it so clear?
It's the only kind of `Tickish` that is scoped, counting and not splittable. This means that we can't * Simply float code out of it, because the payload must still be covered (scoped) * Copy the tick, because it would change entry counts (here: duplicate breakpoints)
Why is it wrong to float a lazy thunk out of a breakpoint?
Good questions - I haven't given breakpoint semantics a lot of thought, to be honest. My assumption was that most optimisation passes would never see them. And where they did, they should just leave them in peace as much as possible. For whatever it's worth, the source cautions against making breakpoints unscoped: {{{ -- Breakpoints are scoped: eventually we're going to do call -- stacks, but also this helps prevent the simplifier from moving -- breakpoints around and changing their result type (see #1531). }}} Hm. We might try to make them pseudo-splittable, with non-counting breakpoints being NOPs for now? This might still allow us to implement breakpoint-based stack traces if we really want them... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar, Type: bug | peter wortman Priority: high | Status: new Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar, peter wortman * priority: normal => high * milestone: => 7.10.1 Comment: Peter, Simon M: can you work together to fix this? A flat-out panic is really not good. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: scpmw (added) * owner: simonmar, peter wortman => simonmar -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): I think the problem here is that you're trying to use `-O` in conjunction with the interpreter, which we normally don't do because optimisation can introduce unboxed tuples, which the interpreter can't handle. I suspect that you've uncovered another case that isn't handled when we try to use -O with the interpreter, but since we don't have any plans to handle that combination I'm not inclined to try to fix this particular problem. We will look into why we aren't catching the -O/interpreter combination and make it fail in a civilized way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): So the fixes needed are: * Complain in a civilised way if you are using the interpreter with `-O`. Add a clear `Note` to explain why, enumerating all the things (that we know of) which can go wrong. * Add a clear Note in `FloatOut` to explain that the un-handled case concerns breakpoints (which isn't at all clear right now), and that breakpoints means the interpreter, and the interpreter means no `-O` (refer to Note from the first bullet). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): (For interested readers, the check we currently have is in `setOptLevel` in `DynFlags.hs`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Is anyone willing to execute on this? Simple, a little fiddly. Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D727 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Compile-time crash -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by George): * failure: Compile-time crash => GHCi crash -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"9736c042f4292b4fb94ca9faca6a010372a0f92f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9736c042f4292b4fb94ca9faca6a010372a0f92f" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"b199536be25ea046079587933cc73d0a948a0626/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b199536be25ea046079587933cc73d0a948a0626" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"091944e3aec736b440a9c1204f152004e382c967/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="091944e3aec736b440a9c1204f152004e382c967" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"2c6a0411dcd921ea6ec1cbe5eaf93d17adcf33a2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2c6a0411dcd921ea6ec1cbe5eaf93d17adcf33a2" Fix a couple of tests for GHCi/-O* (Trac #10052) Tests use unboxed types (or optimizer gets to them), those can't be handled by ghci. Fixed by using -fobject-code. Signed-off-by: Sergei Trofimovich <siarheit@google.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D727 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"44f079f74869d8cb417e2dcc104517ae7f593e5f/ghc" 44f079f7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44f079f74869d8cb417e2dcc104517ae7f593e5f" FloatOut: Allow floating through breakpoint ticks I believe this is actually a completely valid thing to do, despite the arguments put forth in #10052. All that was missing was logic in SetLevels to correctly substitute the cloned binders into the breakpoint's free variable list. This is a prerequisite for enabling StaticPointer support in the interpreter. Test Plan: Validate Reviewers: austin, scpmw Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3049 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC