January 2015 - ghc-tickets

[GHC] #9395: Debug.Trace should not use %s for format string
by GHC 18 Feb '15

18 Feb '15

#9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The current implementation of traceIO in Debug.Trace is as follows: {{{ traceIO :: String -> IO () traceIO msg = do withCString "%s\n" $ \cfmt -> withCString msg $ \cmsg -> debugBelch cfmt cmsg }}} This is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null. Probably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be: {{{ main = trace "\0foo" (return ()) }}} which should have non-empty output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9959: removeDirectoryRecursive should not follow symlinks
by GHC 18 Feb '15

18 Feb '15

#9959: removeDirectoryRecursive should not follow symlinks -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 libraries/directory | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It's just, like, a really bad idea. And almost never what you want. (Also, it differs from the behavior of `rm -rf`). Can we just change the behavior? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9135: readProcessWithExitCode leaks when the program does not exist
by GHC 17 Feb '15

17 Feb '15

#9135: readProcessWithExitCode leaks when the program does not exist -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{#!haskell import Control.Monad import System.Process import qualified Control.Exception as C try' :: IO a -> IO (Either C.SomeException a) try' = C.try main = replicateM_ 1000 $ do try' (readProcessWithExitCode "doesnotexist" [] "") print =<< try' (readProcessWithExitCode "/bin/echo" ["it works"] "") }}} This eventually runs out of file descriptors and fails to start the existing process. Tested with process 1.2.0.0 and GHC 7.8.2 on OS X -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8844: Pseudo terminal and process-1.2.0.0
by GHC 17 Feb '15

17 Feb '15

#8844: Pseudo terminal and process-1.2.0.0 -------------------------------------+------------------------------------- Reporter: ksamborski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Keywords: pty | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, I'm writing simple app which execute process and communicate with it via pseudo terminal. Here is some sample code: import System.Posix.Terminal import System.Process main = do (master, slave) <- openPseudoTerminal hslave <- fdToHandle slave hSetBuffering hslave NoBuffering (_,_,_,ph) <- createProcess (shell "mc"){ env = Just [("TERM", "xterm")] , std_in = UseHandle hslave , std_out = UseHandle hslave , std_err = UseHandle hslave , close_fds = True } forkIO $ readTerm master -- my function which reads output from process waitForProcess ph The problem is that mc still wants some input from stdin but not from slave terminal. But when I changed function runIteractiveProcess from runProcess.c like this: ... /* Reset the SIGINT/SIGQUIT signal handlers in the child, if requested */ if (reset_int_quit_handlers) { struct sigaction dfl; (void)sigemptyset(&dfl.sa_ mask); dfl.sa_flags = 0; dfl.sa_handler = SIG_DFL; (void)sigaction(SIGINT, &dfl, NULL); (void)sigaction(SIGQUIT, &dfl, NULL); } /********************************************************************************/ setsid(); //Make the current process a new session leader ioctl(0, TIOCSCTTY, 1); //As the child is a session leader, set the controlling terminal to be the slave side of the PTY /********************************************************************************/ /* the child */ if (environment) { // XXX Check result execvpe(args[0], args, environment); } else { // XXX Check result execvp(args[0], args); } childFailed(forkCommunicationFds[1], forkExecFailed); ... it worked as expected, I'm not proposing patch or solution but is there any chance to add support for pseudo terminals in the process library? Maybe just add another record field in CreateProcess like pty :: Bool and then call these two additional instructions in runIteractiveProcess? Best regards, Karol Samborski -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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

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

13 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 13 Feb '15

13 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] #9213: CPP warnings on ghcautoconf.h
by GHC 09 Feb '15

09 Feb '15

#9213: CPP warnings on ghcautoconf.h ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The cpphs program yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line `# if defined __BIG_ENDIAN__` has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10036: Update Cabal before final 7.10 release
by GHC 09 Feb '15

09 Feb '15

#10036: Update Cabal before final 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc2 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC. https://github.com/haskell/cabal/pull/2391 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10020: GHC 7.10 rejects nullary type class with associated data
by GHC 09 Feb '15

09 Feb '15

#10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In GHC 7.8.4, the following code is legal: {{{#!hs {-# LANGUAGE NullaryTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} In GHC 7.10, {{{NullaryTypeClasses}}} was [https://ghc.haskell.org/trac/ghc/ticket/8993 deprecated] in favor of {{{MultiParamTypeClasses}}}. However, running this code on GHC 7.10-rc1: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} results in this error: {{{ NullaryData.hs:4:1: The associated type ‘NullaryData’ mentions none of the type or kind variables of the class ‘NullaryClass’ In the class declaration for ‘NullaryClass’ }}} It's probably related to [https://ghc.haskell.org/trac/ghc/ticket/9167 this earlier bugfix]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3