- ghc-tickets - Haskell.org

[GHC] #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid
by GHC 12 Apr '13

12 Apr '13

#7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- poll() is used in GHC/Event/Poll.hsc. The type of its second argument is nfds_t. nfds_t is defined unsigned long on Linux and unsigned int on Mac/FreeBSD. FFI in Poll.hsc uses CULong instead of (#type nfds_t). So, this may cause a problem on Mac/FreeBSD. Actually, a web server compiled by GHC head on FreeBSD sometime causes the following error: {{{ mighty-head: c_poll: invalid argument (Invalid argument) mighty-head: sendWakeup: invalid argument (Bad file descriptor) mighty-head: sendWakeup: invalid argument (Bad file descriptor) mighty-head: sendWakeup: invalid argument (Bad file descriptor) }}} poll() on FreeBSD returns EINVAL when the specified time limit is negative. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7693: Flush .hp file at the end of each sample
by GHC 12 Apr '13

12 Apr '13

#7693: Flush .hp file at the end of each sample -----------------------------+---------------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Tools like hp2any-graph reads a .hp file as it's being written to. However writing to .hp files is currently block-buffered, causing a delay until the latest sample can be read. The attached patch adds a call to fflush every time a complete sample is written. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7727: Nonsense evaluation: sequence [] = []
by GHC 12 Apr '13

12 Apr '13

#7727: Nonsense evaluation: sequence [] = [] -----------------------------+---------------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ $ ghci-7.6.2 GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. >>> sequence [] [] >>> :t it it :: [()] >>> sequence [] :: [()] <interactive>:4:1: Couldn't match type `[a0]' with `()' Expected type: [()] Actual type: [[a0]] In the return type of a call of `sequence' In the expression: sequence [] :: [()] In an equation for `it': it = sequence [] :: [()] }}} Wat. Where on earth did ghci get the idea that {{{ sequence [] = [] }}}? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)
by GHC 12 Apr '13

12 Apr '13

#7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) --------------------------------+------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC with parallel IO manager on Mac freezes when compiling the dph libraries in the phase 2. * This happens only if we specify "-j" to "make". Note that "make" closes stdin of sub-processes if "-j" is specified. * Even if we specify "-j" to "make", the problem disappears with stdout/stderr redirection. That is, "make -jN >& LOG &" works. * The "-d" option of "make" does not make any effects. * Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well. An IO manager is polling a kqueue fd. Another Haskell thread on another native thread registers an event through the same kqueue fd. In many cases, this works on Mac. In a certain situation, MacOS does not deliver an event to the IO manager. If the IO manager gets up and polls the kqueue fd, the event is delivered. This bug only appears when building GHC on Mac. I cannot find a simple way to reproduce it. Even if we find a way to reproduce it, I guess that we will probably reach a conclusion that this is a bug of kqueue of Mac. I have some evidences that kqueue of Mac is buggy: * http://comments.gmane.org/gmane.comp.lib.ev/1871 * http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7644: Hackage docs for base library contain broken links
by GHC 12 Apr '13

12 Apr '13

#7644: Hackage docs for base library contain broken links -----------------------------+---------------------------------------------- Reporter: JulesBean | 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: -----------------------------+---------------------------------------------- http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC- IOArray.html Is a 404, presumably because it's {{{ {-# HADDOCK_OPTIONS hide #-} }}} so the haddocks don't get documented? However it is linked to from the master index http://hackage.haskell.org/package/base-4.6.0.0 ...which as far as I can see has links to all modules irrespective of whether they are hidden or not. A different example relates to source links: If you look at the Prelude docs here: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.h… Then some of the source links point to URLs like http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC- Classes.html#Ord ...which looks like some substitution operation has failed (%01 -> package name, %02 -> version, I presume). An attempt to manually fix the package name and version still leads to a 404. Some other source links from the Prelude are fine, though, for example: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC- Enum.html#Enum This is a regression but I don't know how recently; I certainly used to be able to follow links like that back in the 7.0 era, but I don't when it started failing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7643: Kind application error
by GHC 12 Apr '13

12 Apr '13

#7643: Kind application error -----------------------------+---------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Compiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1. To see the failure: {{{ ghc -dcore-lint --make Main.hs }}} The failure does not occur with GHC 7.4. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7637: split-objs not supported for ARM
by GHC 12 Apr '13

12 Apr '13

#7637: split-objs not supported for ARM -----------------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: arm Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- As reported in http://www.haskell.org/pipermail/ghc- devs/2013-January/000198.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7635: SafeHaskell implying other options
by GHC 12 Apr '13

12 Apr '13

#7635: SafeHaskell implying other options ----------------------------------------+----------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- There have been several type checker bugs -- including #7453 and #7354 -- that have led to type-checker unsafeCoerce/panic/etc., which is a problem under SafeHaskell. In many cases the issue is caught by `-dcore-lint`. I'm not sure how much overhead core-linting has, but it seems like it could be a good idea to turn it on by default at least when SafeHaskell is on. Right now it's listed as a "compiler debugging option", but it seems that common wisdom is that you should use it if you care about security. Should you also use `stg-lint`/`cmm-lint`? Any other options? This should be clearly documented. Relatedly: Earlier today someone was running a Haskell-evaluating IRC bot. It was running with SafeHaskell, but also happened to have GeneralizedNewtypeDeriving turned on, which made it possible to derive `unsafeCoerce`. Should more care be taken that unsafe options are never turned on at the same time as SafeHaskell? (Continued from #7354.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7634: MD5 collision could lead to SafeHaskell violation
by GHC 12 Apr '13

12 Apr '13

#7634: MD5 collision could lead to SafeHaskell violation -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The current scheme for computing `TypeRep` fingerprints is: `md5sum (encodeUTF32BE (unwords [moduleName, packageName, typeName]))`. `SafeHaskell` doesn't allow custom-written `Typeable` instances, but this is more or less the code that `deriving Typeable` generates. MD5 is broken and not collision-resistant. If someone can make an MD5 collision, they could use it to derive `unsafeCoerce` and execute arbitrary code. The constraints (UTF-32, names being alphanumeric, etc.) make it pretty tricky to find a valid collision by the standard methods, but I don't know enough about this to say how feasible it is. It seems to me that, especially with `new-typeable`, it might not be necessary to use hashing at all, if GHC can figure out fingerprints statically. Or maybe separate compilation requirements make that unworkable (in which case maybe using a hash of the package/module name along with a separate per-module counter, or something along those lines, might be better, since people are less likely to control those? I'm not sure). Maybe the solution is just switching to another hash function, or something else. At any rate, the issue should be considered -- using MD5 isn't a good idea in cases where collisions could have security implications. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7654: Cannot specify argv[0] with createProcess
by GHC 12 Apr '13

12 Apr '13

#7654: Cannot specify argv[0] with createProcess -----------------------------+---------------------------------------------- Reporter: MtnViewMark | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/process Version: 7.6.2 | Keywords: process Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- There are conditions where it is important to specify the value of argv[0] as distinct from the FilePath of the file to execute. When createProcess is called with CmdSpec (inside the CreateProcess argument) of RawCommand, the code in System.Process.Internals.runGenProcess_ builds the argv list by concatenating the FilePath of the command to run on to the supplied args, then passing that array to the c code runInteractiveProcess. runInteractiveProcess in turn uses argv[0] as the initial argument to either execvp() or execvpe(). Thus, argv[0], and the command to execute must be the same. The fix is simple, but long.... runInteractiveProcess should take an adiditional parameter that is the command to exec, distinct from the args array (which continues to hold the now distinct argv[0]). runGenProcess_ should keep cmd and args distinct, and build cstrs from args, not cmd:args. commandToProcess needs to then take on the work of prepending the cmd to the args array, in the case of RawCommand or ShellCommand. NOW, we can introduce a new constructore RawCommandWithArg0 FilePath String [String] where argv[0] is specified, and commandToProcess for that can easily build the args from that parameter. I should probably prepare a patch for this.... But I wanted to get the ticket in as the issue was fresh in my mind. This is a feature request, but realize that without a change, an important part of POSIX support is missing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4