February 2015 - ghc-tickets

[GHC] #9266: getDirectoryContents blow its stack in a huge directory
by GHC 17 Feb '15

17 Feb '15

#9266: getDirectoryContents blow its stack in a huge directory -------------------------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Once a directory has around 2 million files in it, a lack of an accumulator in getDirectoryContents (unix version only; windows already has an acc) causes it to blow the stack: {{{ joey@darkstar:‾/src/git-annex>cat test.hs import System.Directory main = do l <- getDirectoryContents "/tmp/big" print (null l) joey@darkstar:‾/src/git-annex>ghc --make -O2 test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... joey@darkstar:‾/src/git-annex>./test Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} I suggest the attached patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #3693: Show stack traces
by GHC 16 Feb '15

16 Feb '15

#3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.10.4 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 Tarrasch): I just opened to phabricator diffs, the first being about stack reification in the rts. The second is more of a vision and probably more interesting to check out, as it's features Stack Traces in Haskell-land. https://phabricator.haskell.org/D661 https://phabricator.haskell.org/D662 Though there is still a lot of work left it seems. Right now, the biggest show-stopper is that D662 depends on the libdwarf library which isn't portable. Peter knows (much) more about this. Peter, care to give an update? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:75> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Feb '15

14 Feb '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:75> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10080: Recusive IO actions crash with segmentation fault
by GHC 14 Feb '15

14 Feb '15

#10080: Recusive IO actions crash with segmentation fault -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am learning Haskell and wrote a program that writes some strings to stdout infinitely by recursing in an IO action. It seems such a simple construct crashes on FreeBSD when Ctrl+C is pressed to interrupt it. I have been able to reduce it to a simple case like this: {{{#!hs main = do putStrLn "hello world" main }}} I compiled it with {{{ ghc --make hello.hs }}} Then pressed Ctrl+C and immediately got: {{{ [...] hello world hello world hello world hello world ^CSegmentation fault (core dumped) }}} Here is the backtrace of the crash: {{{ (gdb) bt #0 0x000000000047cdd7 in generic_handler () #1 0x000000080147c467 in swapcontext () from /lib/libthr.so.3 #2 0x000000080147c062 in sigaction () from /lib/libthr.so.3 #3 <signal handler called> #4 0x00000008017d7b7a in select () from /lib/libc.so.7 #5 0x0000000801479b32 in select () from /lib/libthr.so.3 #6 0x000000000043cb13 in fdReady () #7 0x000000000044751c in base_GHCziIOziFD_zdwa3_info () #8 0x0000000000000000 in ?? () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 13 Feb '15

13 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550, #10079 | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #8550 => #8550, #10079 Comment: Just had a chat with Simon about all of this. We resolved several things: 1. The plumbing I have installed (in Phab:D653), using `FlatM` is helpful, and it caught errors in `shortCutReduction`. 2. Having `FlatM` modify a `CtLoc` is wrong, as it means that a certain `CtEvidence` suddenly has a new depth. This makes no sense. 3. Simon was uncertain about the need to bump the stack depth in `rewriteEqEvidence`. But, after some thought, this is appropriate (in the non-reflexive case): `rewriteEqEvidence` is often called after some flattening, and it's quite possible that the flattening reduced some type families. We debated various schemes where we would bump only if the flattener did indeed reduce a type family (or newtype), and perhaps even bump by just the right number of reductions, but these didn't seem to work out. A central problem is what to do if we flatten, say, `Either (F a) (G b)` to `Either t1 t2`, where `F a` and `G b` took ''different'' numbers of steps to reduce. No handling of this scenario seemed adequate. So, we always bump (in the non-reflexive case). 4. `rewriteEqEvidence` checks for deriveds before reflexivity. These should be reversed. 5. The flattener will count reductions ''separately'' from the canonicalizer. This amounts to plan (2) in comment:13, where the flattener can take `-ftype-function-depth` steps during eager reduction. Then, regardless of the number of steps the flattener took, `rewriteEqEvidence` will bump only by one. So, the actual number of reductions possible is something like the product of the class stack depth and the type function depth. 6. Because of the point above, a programmer has no hope of setting these depths correctly when type families or newtypes reduce. Indeed, exactly when we hit a certain limit is quite likely to change between minor GHC releases. However, these limits are there only to prevent GHC from looping. Once a programmer has written their module, confirms that it compiles in finite time, it is safe just to disable these checks -- GHC will still never produce wrong code; it just might never produce any code at all. Thus, the new recommendation when a programmer hits these limits is just to disable the check. Disabling the check is infinitely more robust than choosing a new, arbitrary limit, likely to change between minor releases. 7. Setting the stack depths to 0 will serve as the marker for infinity. 8. There are other places where 0 means infinity, such as `st_max_ticks` in `SimplMonad.SimplTopEnv` and `TcValidity.TypeSize`. These should be abstracted into a new integer+infinity type, to go in `BasicTypes`. 9. `shortCutReduction` is utterly bogus, and it was a great surprise to Simon that the wheels haven't fallen off. We believe that this function must not be called at all during building GHC and in the testsuite. I will check this, and remove the function if it is unused. It can be fixed fairly easily. But as the name implies, it is simply an optimization. If it never triggers, then there's no reason to keep around taking up space. Simon conjectures that the reason it's not used is due to the new eager type family reduction in the flattener. 10. After all of this is done, it will be possible to move the newtype- unwrapping code into the flattener, with a depth check intact. The work above is expected to fix this ticket, #8550, and #10079. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10085: Type families cause wrapper types to disappear without cause
by GHC 13 Feb '15

13 Feb '15

#10085: Type families cause wrapper types to disappear without cause -------------------------------------+------------------------------------- Reporter: tathougies | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I tried to summarize the bug in the title, but I'm absolutely at a loss to understand what's going on here. Here's the output of a GHCi session: {{{#!hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set -XTypeFamilies Prelude> type family Strange (f :: * -> *) ty where { Strange f ty = Maybe (f ty) } Prelude> newtype Identity a = Identity { runIdentity :: a } Prelude> newtype StrangeHolder f = StrangeHolder (f Int) Prelude> let x = Just (Identity 3) :: Strange Identity Int Prelude> :type x x :: Maybe (Identity Int) Prelude> StrangeHolder _ :: StrangeHolder (Strange Identity) <interactive>:8:15: Found hole ‘_’ with type: Maybe (Identity Int) Relevant bindings include it :: StrangeHolder (Strange Identity) (bound at <interactive>:8:1) In the first argument of ‘StrangeHolder’, namely ‘_’ In the expression: StrangeHolder _ :: StrangeHolder (Strange Identity) In an equation for ‘it’: it = StrangeHolder _ :: StrangeHolder (Strange Identity) Prelude> :type x x :: Maybe (Identity Int) Prelude> StrangeHolder x :: StrangeHolder (Strange Identity) <interactive>:10:15: Couldn't match type ‘Identity Int’ with ‘Int’ Expected type: Maybe Int Actual type: Maybe (Identity Int) In the first argument of ‘StrangeHolder’, namely ‘x’ In the expression: StrangeHolder x :: StrangeHolder (Strange Identity) }}} GHC reports that it is expecting the type `Maybe (Identity Int)` as the first argument to `StrangeHolder`. It also reports that `x` has type `Maybe (Identity Int)`, but when I go to put `x` into a `StrangeHolder`, GHC has seemingly gotten rid of Identity, and now expects `x` to be of type `Maybe Int`. I think this is a bug, since the `Identity` type seems to disappear without cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt
by GHC 12 Feb '15

12 Feb '15

#10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've uncovered an unusual bug with Template Haskell inside of GHCi. To duplicate it, load GHCi, create a data type, then attempt to reify one of its constructors. It will fail the first time, but succeed the second time. {{{ $ ghci -XTemplateHaskell GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. λ> import Language.Haskell.TH λ> data Option a = Some a | None λ> $(reify 'Some >>= stringE . show) Failed to load interface for ‘Ghci1’ no package matching ‘interactive’ was found λ> $(reify 'Some >>= stringE . show) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. "DataConI Ghci1.Some (ForallT [PlainTV a_1627392303] [] (AppT (AppT ArrowT (VarT a_1627392303)) (AppT (ConT Ghci1.Option) (VarT a_1627392303)))) Ghci1.Option (Fixity 9 InfixL)" }}} Curiously, this doesn't happen when you reify a data constructor in {{{base}}}, such as {{{Just}}}: {{{ $ ghci -XTemplateHaskell GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. λ> import Language.Haskell.TH λ> $(reify 'Just >>= stringE . show) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. "DataConI Data.Maybe.Just (ForallT [PlainTV a_1627398816] [] (AppT (AppT ArrowT (VarT a_1627398816)) (AppT (ConT Data.Maybe.Maybe) (VarT a_1627398816)))) Data.Maybe.Maybe (Fixity 9 InfixL)" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9674: Foldable doesn't have any laws
by GHC 12 Feb '15

12 Feb '15

#9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The documentation for `Foldable` doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10084: Data.List should have a takeLastN function
by GHC 12 Feb '15

12 Feb '15

#10084: Data.List should have a takeLastN function -------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A natural compliment to the `take` function that instead takes `n` elements from the end of the list rather than from the start would be very useful. I'm surprised it's not defined in base because it seems to be a common operation that is not trivial to define in an efficient way. See http://www.joachim- breitner.de/blog/600-On_taking_the_last_n_elements_of_a_list -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10082: Church Booleans - xor
by GHC 11 Feb '15

11 Feb '15

#10082: Church Booleans - xor -------------------------------------+------------------------------------- Reporter: honza889 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I use following implementation of Church Booleans, all is ok: {{{#!hs lTrue = \x y -> x lFalse = \x y -> y lNot = \t -> t lFalse lTrue lXor = \u v -> u (lNot v) (lNot lNot v) lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse) }}} But this simplified versions of lXor fails, if first parameter is lFalse: {{{#!hs lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc? lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc? }}} {{{#!hs GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 <interactive>:3:1: Non type-variable argument in the constraint: Num (t5 -> t4 -> t5) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 <interactive>:3:24: Could not deduce (Num (t20 -> t30 -> t30)) arising from the literal ‘1’ from the context (Num (t5 -> t4 -> t5)) bound by the inferred type of it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5 at <interactive>:3:1-26 The type variables ‘t20’, ‘t30’ are ambiguous In the third argument of ‘lXor''’, namely ‘1’ In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for ‘it’: it = (lXor'' lFalse lFalse) 1 0 }}} Because both lXor implementations in first example works ok, I believe this is bug in ghc. But similar problem occure in older versions of ghc: {{{#!hs GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l lambda.hs [1 of 1] Compiling Main ( lambda.hs, interpreted ) Ok, modules loaded: Main. *Main> (lXor'' lFalse lFalse) 1 0 <interactive>:3:24: No instance for (Num (t20 -> t30 -> t30)) arising from the literal `1' Possible fix: add an instance declaration for (Num (t20 -> t30 -> t30)) In the third argument of lXor'', namely `1' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 <interactive>:3:26: No instance for (Num (t50 -> t40 -> t50)) arising from the literal `0' Possible fix: add an instance declaration for (Num (t50 -> t40 -> t50)) In the fourth argument of lXor'', namely `0' In the expression: (lXor'' lFalse lFalse) 1 0 In an equation for `it': it = (lXor'' lFalse lFalse) 1 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3