April 2013 - ghc-tickets

[GHC] #7815: STM fails to validate read.
by GHC 17 Apr '13

17 Apr '13

#7815: STM fails to validate read. ----------------------------------------+----------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: STM Os: Unknown/Multiple | Architecture: x86 Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This issue was brought up by napping in {{{#haskell}}} with this paste: [http://hpaste.org/85134] (the first paste in particular) The code is: {{{ import Control.Concurrent.STM import Control.Concurrent import Control.Monad main = do dog <- newTVarIO False cat <- newTVarIO False let unset = do d <- readTVar dog c <- readTVar cat if (d || c) then retry else return () setDog = unset >> writeTVar dog True setCat = unset >> writeTVar cat True oops = do d <- readTVar dog c <- readTVar cat guard (d && c) reset = do writeTVar dog False writeTVar cat False reset' = do d <- readTVar dog c <- readTVar cat guard (d || c) reset forkIO (atomically oops >> putStrLn "Oh Noes!") forever (do forkIO (atomically setDog) forkIO (atomically setCat) atomically reset' atomically reset') }}} When run it produces: {{{ $ ghc --make test.hs -threaded -rtsopts $ ./test +RTS -N2 Oh Noes! test: thread blocked indefinitely in an STM transaction }}} The second message is just a consequence of entering an unexpected state. The first message indicates that both the transactions {{{cat}}} and {{{dog}}} committed at the same time. It does this for HEAD and 7.6. I've sketched out an interleaving that leads to this. TRec entries are in the first and third column and TVar's are in the second column. Each entry has a TVar name and the expected value followed by the new value and then a number of updates if it has been read. TVars list their value and their number of updates. {{{ A TRec TVar B TRec -- Transactions start cat F F cat F 0 cat F F -- Initial reads. dog F F dog F 0 dog F F cat F T dog F T -- Local writes in TRec's -- Validation: cat F F 0 -- B reads num_updates from cat (with ^ -- consistency check with value) cat F T cat A 0 | -- A acquires lock for cat (atomic cas) dog F F 0 ^ | -- A reads num_updates from dog (with ^ | | -- consistency check with value) | dog B 0 dog F T | -- B acquires lock for dog (atomic cas) | | ^ | | | | | Success 0 | 0 | -- read check for A Success 0 0 -- read check for B cat A 1 -- Increment version cat T 1 -- Unlock with new value dog B 1 -- Increment version dog B T -- Unlock with new value }}} What is clear here is that the version number is not enough to check in {{{check_read_only}}} because there is a gap between locking and incrementing the version. We need to know atomically that the TVar is not locked and it's version number is the same. I need to read through the right parts of Keir Fraser's thesis carefully, but it seems like the read phase here is only helpful in preventing a commit that writes back the exact value we have already seen while we are in the middle of committing. The code for {{{check_read_only}}} is here: {{{ #!c static StgBool check_read_only(StgTRecHeader *trec STG_UNUSED) { StgBool result = TRUE; ASSERT (config_use_read_phase); IF_STM_FG_LOCKS({ FOR_EACH_ENTRY(trec, e, { StgTVar *s; s = e -> tvar; if (entry_is_read_only(e)) { TRACE("%p : check_read_only for TVar %p, saw %ld", trec, s, e -> num_updates); if (s -> num_updates != e -> num_updates) { // ||s -> current_value != e -> expected_value) { TRACE("%p : mismatch", trec); result = FALSE; BREAK_FOR_EACH; } } }); }); return result; } }}} If I restore the commented out line (which appears commented out in the first commit of this code that I can find) I can't reproduce the issue, but I think there is still a problem due to the ordering of those checks: we could observe the version as the same, while it is locked, have the TVar unlock, then observe the value the same. Switching the order we can only observe the TVar unlocked if the update has been incremented (as long as we are on an architecture that ensures this such as x86). Does this seem right? One issue is that given the interleaving that above with this added check ''both'' transactions could fail to commit. I think the algorithms from Fraser avoid this, but I think it always involves invalidating another transaction (i.e. killing off any other transactions observed to be in the read check phase with an overlapping TVar in a way that results in only one winner (see page 21 section 4.4 in ''Concurrent Programming Without Locks'')). As a side note, the issue can be avoided by ensuring that the reads become writes and avoiding the read only check. But you can only become a write if the values do not have matching pointers, switching to Ints instead of Bools gets you there. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7748: Runtime <<loop>> due to incorrect inferred type
by GHC 17 Apr '13

17 Apr '13

#7748: Runtime <<loop>> due to incorrect inferred type ----------------------------------------+----------------------------------- Reporter: jbransen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- There is a bug in the type checker of 7.6.1 and 7.6.2, which accepts an incorrect type resulting in <<loop>> at runtime. Furthermore, 7.6.2 even automatically infers this incorrect type. Hence, the attached code has the following behavior: - No explicit type: Code works in 7.6.1, loops in 7.6.2 - Correct explicit type: Code works fine in 7.6.1 and 7.6.2 - Incorrect explicit type: Code loops in 7.6.1 and 7.6.2 The incorrect type has a parameter that is too polymorphic, i.e. an "a" type is accepted while the function does a pattern match on the parameter from which it is clear that it should be a Maybe type. In 7.4.* versions this incorrect type is not accepted. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6135: Unboxed Booleans
by GHC 16 Apr '13

16 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonpj): Also, use the stage-1 compiler to generate code for some tiny program like {{{ f x = if x>0 then True else False g x = x<0 }}} and check that the comparison is going to work right. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
by GHC 16 Apr '13

16 Apr '13

#7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion --------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: perf/should_runt/T7436 | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by simonpj): This one is fixed, just awaiting merging into 7.6.3 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7436#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7586: :kind command cannot show kind of type synonyms
by GHC 16 Apr '13

16 Apr '13

#7586: :kind command cannot show kind of type synonyms -----------------------------+---------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following illustrates the problem: {{{ Prelude> type T a = Int Prelude> :k T <interactive>:1:1: Type synonym `T' should have 1 argument, but has been given none In a type in a GHCi command: T }}} Undoubtedly, T has a kind, and there's no reason to insist that the type given to the :kind command should be fully applied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7837: Rules involving equality constraints don't fire
by GHC 16 Apr '13

16 Apr '13

#7837: Rules involving equality constraints don't fire ------------------------------------+--------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: equality constraint,rules Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- In the attached program, the "normalize/Double" rule doesn't fire, whereas "normalize'/Double" does. In general, it seems that a rule doesn't fire if it involves discharging an equality constraint that is required by the LHS. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7816: "main function" is not a function
by GHC 16 Apr '13

16 Apr '13

#7816: "main function" is not a function ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- A module without main gives an error: {{{ A.hs:1:1: The function ‛main’ is not defined in module ‛Main’ }}} However, main in Haskell is not a function. This is often a cause of misunderstandings, for example see [http://ircbrowse.net/browse/haskell?q=main+not+function IRC discussions] or [http://conal.net/blog/posts/everything-is-a-function-in-haskell Conal Elliott's "Everything is a function in Haskell"]. I suggest changing this to: {{{ A.hs:1.1: The IO action ‛main’ is not defined in module ‛Main’ }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #6135: Unboxed Booleans
by GHC 16 Apr '13

16 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by benl): Ok, then find the smallest possible program that segfaults, then look at the Cmm and assembly code to see what's changed. You'll particularly want to ensure that the base libraries are built with the original working compiler, but then build only your test programs with the hacked compiler. There is also a "Debugging GHC" guide on the developers wiki. It might be time to learn how to use GDB. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4185: Deriving higher-arity instances for newtype family instances fails
by GHC 15 Apr '13

15 Apr '13

#4185: Deriving higher-arity instances for newtype family instances fails ---------------------------------+------------------------------------------ Reporter: LouisWasserman | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by sjoerd_visscher): DeriveFunctor has the same problem: {{{ data family D x :: * -> * data instance D () a = X a deriving Functor }}} gives {{{ Derived instance `Functor (D ())' requires illegal partial application of data type family D In the data instance declaration for `D' }}} While implementing the instance by hand works fine: {{{ instance Functor (D ()) where fmap f (X a) = X (f a) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4185#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7838: ghc(i) crashes on instance declaration
by GHC 15 Apr '13

15 Apr '13

#7838: ghc(i) crashes on instance declaration -----------------------------+---------------------------------------------- Reporter: alios | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: MultiParamTypeClasses Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ multiple lines, ''no wiki'' {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, ConstraintKinds, UndecidableInstances, FunctionalDependencies, FlexibleInstances #-} {- after declaring the instance instance TS TST TT m where below my ghci crashes on arch linux x86_64, if you comment it out no crash happens. ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): getClassPredTys <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -} module Crash where class T t where type TPI t :: * class (T t, C (TPI t) m (TPI t)) => TC c t m | c -> t class (T t, C (TPI t) m (TPI t)) => TS s t m | s -> t data C i m o data TST data TT instance TS TST TT m where }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1