April 2014 - ghc-tickets

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #8539: Data.Complex shouldn't use default implementation of (**)
by GHC 23 Feb '15

23 Feb '15

#8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ Prelude Data.Complex> 0**2 0.0 Prelude Data.Complex> 0**2 :: Complex Double NaN :+ NaN Prelude Data.Complex> exp $ 2 * log 0 :: Complex Double NaN :+ NaN Prelude Data.Complex> log 0 :: Complex Double (-Infinity) :+ 0.0 Prelude Data.Complex> 2 * it :: Complex Double (-Infinity) :+ NaN Prelude Data.Complex> exp it :: Complex Double NaN :+ NaN }}} So Complex uses the default implementation of (!**). Then when 2*(-inf :+ 0) is evaluated. We do (2 * -inf - 0*0) :+ (2*0 + -inf*0). Which because of -inf*0 sets the imaginary part to NaN. Then exp (-inf :+ NaN) = exp x cos y :+ exp x sin y which becomes 0 * cos NaN :+ 0 * sin NaN. So we end up with NaN :+ NaN. Ross Paterson suggested: I would say the default implementation of (!**) is wrong: to match the Float/Double instances it should be x !** y = if x == 0 then 0 else exp (log x * y) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44

[GHC] #8309: traceEvent truncates to 512 bytes
by GHC 23 Feb '15

23 Feb '15

#8309: traceEvent truncates to 512 bytes ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: eventlog tracing | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `Debug.Trace.traceEvent` (& `traceEventIO`) use a code path that unnecessarily uses printf format strings and uses a fixed size 512-byte buffer, hence truncating all user trace messages at that size. Here is the call path: * `Debug.Trace.traceEvent` (& `traceEventIO`) call `traceEvent#` primop * cmm impl of the primop `stg_traceEventzh` calls C RTS function `traceUserMsg` * `traceUserMsg` calls `traceFormatUserMsg(cap, "%s", msg);`, using the printf format string * `traceFormatUserMsg` uses `postUserMsg` which eventually calls `postLogMsg` * `postLogMsg` does the printf stuff Here's what `postLogMsg` does: {{{ #define BUF 512 void postLogMsg(EventsBuf *eb, EventTypeNum type, char *msg, va_list ap) { char buf[BUF]; nat size; size = vsnprintf(buf,BUF,msg,ap); if (size > BUF) { buf[BUF-1] = '\0'; size = BUF; } .... }}} This is obviously designed for RTS-internal users, not the user path. So the problem starts with this bit: {{{ void traceUserMsg(Capability *cap, char *msg) { traceFormatUserMsg(cap, "%s", msg); } }}} It just should not use that code path. It should call something that directly posts the message, without any silly printf strings. In fact, the code path from the primop down should really be changed to use an explicit given length, rather than using a null-terminated string and having to call strlen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8546: Panic during cabal build with profiling enabled.
by GHC 23 Feb '15

23 Feb '15

#8546: Panic during cabal build with profiling enabled. ---------------------------------+--------------------------------------- Reporter: Mokosha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cabal sandbox | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------+--------------------------------------- I had been recently using cabal-dev for my development work. Someone suggested I switch over to the new cabal 1.18 on #haskell. After doing so, some projects do not seem to build anymore. I'm not an experienced Haskell developer, so I'm not sure how to go about debugging such a problem. I've included the output of the install command. {{{ Pavel@ZOMBIE-POWER ~/Projects/Lambency/src $ cabal install -p Resolving dependencies... Configuring bindings-GLFW-3.0.3.1... Building bindings-GLFW-3.0.3.1... Preprocessing library bindings-GLFW-3.0.3.1... [1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.o ) [1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox- 2b66993e\build\Bindings\GLFW.p_o ) In-place registering bindings-GLFW-3.0.3.1... Installing library in D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows- ghc-7.6.3\bindings-GLFW-3.0.3.1 Registering bindings-GLFW-3.0.3.1... Installed bindings-GLFW-3.0.3.1 Configuring GLFW-b-1.4.1... Building GLFW-b-1.4.1... Preprocessing library GLFW-b-1.4.1... [1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics\UI\GLFW\Types.hs, dist\dist-sandbox-2b66993e\build\Graphics\UI\GLFW\Types.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bindings-DSL-1.0.20 ... linking ... done. Loading package bindings-GLFW-3.0.3.1 ... ghc.exe: Unknown PEi386 section name `.drectve' (while processing: D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows- ghc-7.6.3\bindings-GLFW-3 .0.3.1\libHSbindings-GLFW-3.0.3.1.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): loadArchive "D:\\MinGW\\msys\\1.0\\home\\Pavel\\Projects\\Lambency\\build\\i386 -windows-ghc-7.6.3\\bindings-GLFW-3.0.3.1\\libHSbindings-GLFW-3.0.3.1.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install GLFW-b-1.4.1 cabal.exe: Error: some packages failed to install: GLFW-b-1.4.1 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8362: Filesystem related tests failed on solaris (SmartOS)
by GHC 22 Feb '15

22 Feb '15

#8362: Filesystem related tests failed on solaris (SmartOS) --------------------------+------------------------------------------------ Reporter: leroux | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries (other) | Operating System: Solaris Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Getting filesystem (files/permissions) related test faiures on SmartOS (32bit). {{{ $ uname -a SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris }}} Unexpected failures: `TEST="openFile003 getPermissions001 processGroup002 user001 posix005"` The testsuite output is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8280: Deriving Show for Word#
by GHC 20 Feb '15

20 Feb '15

#8280: Deriving Show for Word# ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ {-# LANGUAGE MagicHash #-} import GHC.Prim data A = A Word# deriving Show }}} This works in 7.6.3, but 7.7 gives {{{ Can't find interface-file declaration for data constructor GHC.Types.W# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} The same file works if Word# is replaced by Int#. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9054: runghc-<version> does not call ghc of the same version
by GHC 18 Feb '15

18 Feb '15

#9054: runghc-<version> does not call ghc of the same version ------------------------------------+------------------------------------- Reporter: EyalLotem | 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: | ------------------------------------+------------------------------------- When I ran runghc-7.6.3, it actually executed "/usr/local/bin/ghc" which points to ghc-7.8.2. The offending line is inside the runghc-<version> script: {{{ exec "$executablename" -f "$bindir/ghc" ${1+"$@"} }}} Which should be: {{{ exec "$executablename" -f "$bindir/ghc-<version>" ${1+"$@"} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #8796: -ddump-splices prints to error stream
by GHC 05 Feb '15

05 Feb '15

#8796: -ddump-splices prints to error stream -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I just noticed that unlike other dump flags, `-ddump-splices` dumps to the error stream. I don't think this difference in behaviour is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9004: Add sortOn function to Data.List
by GHC 05 Feb '15

05 Feb '15

#9004: Add sortOn function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The following passed for two weeks on the libraries mailing list without any dissenting votes. The request is to add the following function to Data.List: {{{ -- | Sort a list by comparing the results of a key function applied to each -- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the -- performance advantage of only evaluating @f@ once for each element in the -- input list. This is called the decorate-sort-undecorate paradigm, or -- Schwartzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` (y, x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5