June 2013 - ghc-tickets

[GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x
by GHC 17 Jun '13

17 Jun '13

#7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x ---------------------+------------------------------------------------------ Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Linux | Architecture: Other Failure: Other | Blockedby: Blocking: | Related: ---------------------+------------------------------------------------------ On Debian's s390x architecture (64-bit S/390, Linux kernel), builds of several packages hang with GHC 7.6 where they did not hang with GHC 7.4. In particular, ghc itself hangs during its own build when bootstrapping with 7.6. This is quite easy to reproduce on affected systems, although it doesn't hang in exactly the same place every time. It appears that the runtime sometimes deadlocks when a subprocess exits; the strace looks like this: {{{ 7523 exit_group(0) = ? 6680 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) 6680 --- SIGCHLD (Child exited) @ 0 (0) --- 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) 6680 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- 6680 sigreturn() = ? (mask now []) 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) 6680 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- 6680 sigreturn() = ? (mask now []) 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) [repeats forever] }}} ghc spawns enough subprocesses (gcc etc.) that it's essentially bound to hit this sooner or later. I suspect perhaps a lack of signal-safety somewhere - at an extremely wild guess, perhaps the type of an important variable written in a signal handler happens to exceed the size of sig_atomic_t on s390x and not elsewhere - but I haven't yet been able to track this down in the time available to me. If you don't immediately recognise this as something obvious, then perhaps somebody more fluent in Haskell than I would be good enough to suggest test code that exercises this and is somewhat simpler than "build ghc"? If my analysis is at all close to the mark, then something that sits in a loop forking and reaping a trivial child process on each iteration should be enough to reproduce this. On the assumption that most non-Debian- developers don't have convenient access to S/390 machines (Debian developers can use zelenka.debian.org) I'd be happy to try things out. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
by GHC 17 Jun '13

17 Jun '13

#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------+-------------------------------------------- Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by joeyadams): Replying to [comment:15 igloo]: > So what's the proposal here exactly? Is it to deprecate these?: > {{{ > System.IO.hGetBufSome > System.IO.hGetBufNonBlocking > System.IO.hPutBufNonBlocking > Data.ByteString.hGetNonBlocking > Data.ByteString.hPutNonBlocking > }}} > > There are a couple of uses of `hGetNonBlocking` in haskeline. No, keep `hGetBufSome`. It's useful for reading lines of text from a socket, without waiting for some arbitrary limit to be reached, and without reading a byte at a time. haskeline only uses `System.IO.hWaitForInput` and `Data.ByteString.hGetNonBlocking` for compatibility with GHC < 7.4.1, which does not have working encoding support (see #5436). Thanks for pointing these out. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Slides: http://community.haskell.org/~simonmar/Stack-traces.pdf -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): The relevant code in the compiler is `CoreSyn.Tickish`, `CoreUtils.mkTick`, and `Simplify.simplTick`. In the RTS it is in `rts/Profiling.c`, in particular `EnterFunCCS`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): If you're interested in attacking this, you might want to join forces with Edward Yang who has been working on using CCSs to implement resource limits. The semantics we use in GHC isn't written up anywhere, but the essential details are in my Haskell Implementer's talk last year: http://www.youtube.com/watch?v=J0c4L-AURDQ, and there is more in my WG 2.8 talk. The slides for the latter are on the community server I think, but I can't reach it right now (maybe it's down). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nr): I think a simple static analysis could produce some information of use. I understand that the cost-centre stack is dynamic, but I bet a static approximation could be useful. If I wish to revisit the semantics, is the TOPLAS paper the right starting point, or is there something more recent? Also, can anyone suggest which modules in the compiler would be the ones to inspect? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Jun '13

17 Jun '13

#6018: Injective type families ----------------------------------------+----------------------------------- Reporter: lunaris | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: TypeFamilies, Injective | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4259 | ----------------------------------------+----------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6018#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 17 Jun '13

17 Jun '13

#7259: Eta expansion of products in System FC ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Just by way of concrete example, here's the smallest example Edward wants to do: {{{ {-# LANGUAGE PolyKinds, DataKinds, GADTs #-} import Prelude hiding (id, (.)) class Category (k :: x -> x -> *) where id :: k a a (.) :: k b c -> k a b -> k a c data P :: (x -> x -> *) -> (y -> y -> *) -> (x,y) -> (x,y) -> * where P :: m a b -> n c d -> P m n '(a,c) '(b,d) instance (Category m, Category n) => Category (P m n) where -- id = P id id P lf rf . P lg rg = P (lf . lg) (rf . rg) }}} The addition of id there causes it to fail to typecheck, because refining the kind to `(x,y)` doesn't let it know all types have the form `'(a,b)`. It can't because `Any` still exists as a distinguishable member of every kind, so such a refinement would (currently) be unsound. When we try to build indexed monad transformers we wind up wanting to take product over their indices. Similar issues arise when trying to compute with collages of profunctors and other nifty theoretical toys that have proven quite useful in the `lens` package. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7259#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 17 Jun '13

17 Jun '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Component: Template Haskell Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to be able to have something like this in the Q monad: type MessageName = String -- or something better, I don't know writeIface :: (Quasi q, Serializable a) => MessageName -> a -> q () readIfaces :: (Quasi q, Serializable a) => MessageName -> q [a] Or instead of returning [a], I'm of course fine with a Monoid, I just need the gathered results for every occurrance of the MessageName. This has to be in the interface file, because I'd like this to work through compilation units, like class instances, I'd like to get every result in the readIfaces call that is ever imported from the current module (transitive closure). Please note, that in a very hacky way this is already possible to do by abusing classes. Namely, I create an empty class for my message type. When I want to send a message, I create a new empty datatype named for the message and I make this an instance of the class. Then on the receiving side I just have to reify the class and I will receive all my instance names/messages. This came up while implementing the HFlags library: http://hackage.haskell.org/package/hflags Maybe I shouldn't be proud of this, but we currently do the hacky way explained above. I would love to have a clean approach. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

Re: [GHC] #7952: Can cost-centre annotations be included in -ddump-simpl?
by GHC 17 Jun '13

17 Jun '13

#7952: Can cost-centre annotations be included in -ddump-simpl? ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Core | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Sadly the situation with Cost Centre Stacks is that it's still work in progress and I didn't manage to document it (beyond comments in the code) before I left MSR. Simon is right that you can't statically determine which CCS a particular allocation will be attributed to. However, if the `let` is within the scope of a particular SCC, then the allocation should be attributed to Cost Centre Stacks that have that SCC label on the top. There might be many such stacks in the profile, if the current function was called from multiple different places. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7952#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0