November 2016 - ghc-tickets

Re: [GHC] #1791: heap overflow should generate an exception
by GHC 30 Nov '16

30 Nov '16

#1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): There are a few questions to nail down, like under what precise conditions the exception is thrown, and to which threads. The actual implementation probably isn't all that difficult. Start by making a proposal? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1791#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1791: heap overflow should generate an exception
by GHC 30 Nov '16

30 Nov '16

#1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rwbarton: @@ -0,0 +1,10 @@ + Heap overflow should produce a `HeapOverflow` exception that can be + caught, rather than shutting down the entire RTS immediately. + + [Original ticket description follows. The submitter happened to expose + another bug, which was that heap overflow was not detected at all when a + single allocation exceeded the maximum heap size. The program below now + exits with a "Heap exhausted" message.] + + ---- + New description: Heap overflow should produce a `HeapOverflow` exception that can be caught, rather than shutting down the entire RTS immediately. [Original ticket description follows. The submitter happened to expose another bug, which was that heap overflow was not detected at all when a single allocation exceeded the maximum heap size. The program below now exits with a "Heap exhausted" message.] ---- I want to use the -M option for the goals that are stated in the manual. {{{ ./TestProgram +RTS -M5m -RTS }}} Expected output: {{{ Something like "out of heap space" }}} Actual result: {{{ Machine going into a state where it swaps memory }}} This is the code for TestProgram: {{{ import Control.Monad.ST import Data.Array.ST import Data.Array.MArray import Data.Array.Base(unsafeNewArray_) main = print (runST (do make_empty_table >> return ())) make_empty_table:: ST s (STArray s (Int, Int) (Maybe ep)) make_empty_table = unsafeNewArray_ ((1, 1), (16384, 16384)) }}} This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1791#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12900: Common up identical info tables
by GHC 30 Nov '16

30 Nov '16

#12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs data Bool' = No | Yes }}} It is clear that this is identical to `Bool` at runtime, and so GHC should be able to reuse `Bool`'s code. The same holds for all other pairs of isomorphic data types. I think that a **massive** space savings could be achieved this way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1791: heap overflow should generate an exception
by GHC 30 Nov '16

30 Nov '16

#1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: simonmar (added) Comment: How difficult would this be to actually implement? I can think of several valid use cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1791#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $
by GHC 30 Nov '16

30 Nov '16

#12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [14 of 15] Compiling TieKnot ( GameDefinition/TieKnot.hs, dist/build/LambdaHack/LambdaHack-tmp/TieKnot.dyn_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 8813 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} when compiling in profiling mode the following commit (tons of INLINE and INLINABLE to ensure specialization and a couple more to debug irregularities in the output of the profiler) https://github.com/LambdaHack/LambdaHack/commit/842070fe78f07e2fb0bce829505… Steps to reproduce: {{{ 1. make configure-prof 2. cabal build }}} when I instead do {{{ cabal build --ghc-option=-fsimpl-tick-factor=200 }}} it compiles, though when I touch only `GameDefinition/Main.hs` I always get {{{ ~/r/LambdaHack$ cabal build --ghc-option=-fsimpl-tick-factor=200 Building LambdaHack-0.5.1.0... Preprocessing library LambdaHack-0.5.1.0... Preprocessing executable 'LambdaHack' for LambdaHack-0.5.1.0... [15 of 15] Compiling Main ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.dyn_o ) The interface for ‘TieKnot’ Declaration for tieKnot Unfolding of tieKnot: Iface id out of scope: standardKeys1 [15 of 15] Compiling Main ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.p_o ) The interface for ‘TieKnot’ Declaration for tieKnot Unfolding of tieKnot: Iface id out of scope: standardKeys1 Linking dist/build/LambdaHack/LambdaHack ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10510: Testsuite driver does not run tests in parallel on Windows
by GHC 30 Nov '16

30 Nov '16

#10510: Testsuite driver does not run tests in parallel on Windows -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `testsuite/driver/runtests.py` contains the following 3 lines: {{{ if windows: print("Warning: Ignoring request to use threads as running on Windows") config.use_threads = 0 }}} They were introduced in commit e9b3d6cc65c0b69bd4a50bfa7bc7e1d3536446a8: {{{ Author: Ian Lynagh <> Date: Wed Oct 28 17:54:21 2009 +0000 Don't use threads on Windows It seems to cause some sort of deadlock }}} I tried removing them (Windows 64 bit, using msys2), but then running validate doesn't get any further than: {{{ ... =====> Overlap3(normal) 1605 of 4525 [2, 7, 0] =====> Overlap4(normal) 1606 of 4525 [2, 7, 0] =====> Overlap5(normal) 1607 of 4525 [2, 7, 0] =====> Overlap6(normal) 1608 of 4525 [2, 7, 0] =====> Overlap7(normal) 1609 of 4525 [2, 7, 0] =====> Overlap9(normal) 1610 of 4525 [2, 7, 0] }}} It would be great if we could run the testsuite in parallel again, since running validate takes forever currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12587: InstanceSigs doesn't work with ambigous types
by GHC 30 Nov '16

30 Nov '16

#12587: InstanceSigs doesn't work with ambigous types -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Why this code: {{{#!hs {-# LANGUAGE ScopedTypeVariables, InstanceSigs, AllowAmbiguousTypes #-} module Bug where class Foo a class Bar a where bar :: forall b. (Foo b) => a instance Bar Int where bar :: forall b. (Foo b) => Int -- error here bar = undefined where x :: b x = undefined }}} is rejected with message: {{{ Error: * Could not deduce (Foo b0) from the context: Foo b bound by the type signature for: bar :: Foo b => Int at Bug.hs:11:12-35 The type variable `b0' is ambiguous * When checking that: forall b. Foo b => Int is more polymorphic than: forall b. Foo b => Int When checking that instance signature for `bar' is more general than its signature in the class Instance sig: forall b. Foo b => Int Class sig: forall b. Foo b => Int In the instance declaration for `Bar Int' }}} ? Where does `b0` type var come from? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12902: Improve handle decoding error messages
by GHC 30 Nov '16

30 Nov '16

#12902: Improve handle decoding error messages -------------------------------------+------------------------------------- Reporter: Profpatsch | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When handle decoding encounters a byte sequence it cannot handle and `ErrorOnCodingFailure` is set, at the moment [https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.IO.Encoding.F… an IO error with a pretty non-descriptive messages is thrown] (`invalid byte sequence`). The user should get a bit more Information in that case: 1) What was the byte sequence that caused the error (and if possible where in the input, of course hard with handles) 2) A stack trace of the functions that caused this (probably from `hGetContents` and similar upwards It’s a very hard-to-debug error with the current implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’)
by GHC 30 Nov '16

30 Nov '16

#12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Opening a ticket for discussion. As mentioned in [https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_cha… this comment], more functions can be generalized to `Foldable` {{{#!hs catMaybes :: Foldable f => f (Maybe a) -> [a] mapMaybe :: Foldable f => (a -> Maybe b) -> (f a -> [b]) listToMaybe :: Foldable f => f a -> Maybe a }}} I think `catMaybes` and `mapMaybe` are fine candidates. The comment offers more extreme changes, {{{#!hs catMaybes :: (Foldable f, Foldable g) => Foldable f => f (g a) -> [a] mapMaybes :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 30 Nov '16

30 Nov '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @awson never put his patches up. So at the moment, `-split-sections` does not work on PE targets. So no, you can't flip it on yet. I'm working on getting things up and running. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0