May 2014 - ghc-tickets

[GHC] #8939: Should check the return value of clock_gettime
by GHC 08 Jun '14

08 Jun '14

#8939: Should check the return value of clock_gettime -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 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: -------------------------------------------+------------------------------- In `ghc-7.6.3/rts/posix/GetTime.c`, function `StgWord64 getMonotonicNSec(void)`: The return value of `clock_gettime` should be checked, and if the value is not 0 (success), it should fall back to `gettimeofday`. The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -84,19 +82,22 @@ #ifdef HAVE_CLOCK_GETTIME struct timespec ts; + int res= clock_gettime(CLOCK_ID, &ts); + if(res==0) return (StgWord64)ts.tv_sec * 1000000000 + (StgWord64)ts.tv_nsec; #elif defined(darwin_HOST_OS) uint64_t time = mach_absolute_time(); return (time * timer_scaling_factor_numer) / timer_scaling_factor_denom; -#else +#endif + { //fallback struct timeval tv; gettimeofday(&tv, (struct timezone *) NULL); return (StgWord64)tv.tv_sec * 1000000000 + (StgWord64)tv.tv_usec * 1000; -#endif + } } Time getProcessElapsedTime(void) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8973: Fewer CPSZ: lines with -dshow-passes
by GHC 08 Jun '14

08 Jun '14

#8973: Fewer CPSZ: lines with -dshow-passes ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- `-dshow-passes` generates {{{ *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: }}} All those CPSZ things are not helping! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure
by GHC 08 Jun '14

08 Jun '14

#8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 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: -------------------------------------------+------------------------------- In GHC 7.6, `rts/posix/GetTime.c, Time getProcessCPUTime(void)`: if the result of `clock_gettime` is not zero (success), then the function should fall back to getrusage below instead of aborting with {{{ sysErrorBelch("clock_gettime"); stg_exit(EXIT_FAILURE); }}} The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -64,10 +64,8 @@ res = clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts); if (res == 0) { return SecondsToTime(ts.tv_sec) + NSToTime(ts.tv_nsec); - } else { - sysErrorBelch("clock_gettime"); - stg_exit(EXIT_FAILURE); } + // else fallback } #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8942: Duplicate symbol error when loading an archive twice
by GHC 08 Jun '14

08 Jun '14

#8942: Duplicate symbol error when loading an archive twice ------------------------------------+------------------------------- Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- ghci can load packages from object files (*.o) and from archive files (*.a). When an object file is loaded twice, the second attempt is silently ignored. When an archive file is loaded twice, ghci aborts with the message "fatal error: I found a duplicate definition for symbol ''s''", for the first symbol ''s'' in the archive. === Patch The attached patch changes {{{rts/Linker.c}}} so that loading an archive file twice silently ignores the second attempt, just like it does with object files. === Repro steps Install a package using Cabal 1.18.*, as that version only produces archives and not objects. Then, force ghci to load that package twice. One way to do this is to use hint inside ghci to load a value from the package. {{{ $ ghci > import Hello > import Language.Haskell.Interpreter > r <- runInterpreter $ setImports ["Hello"] >> interpret "Hello" (as :: Hello) Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package Cabal-1.16.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.9.0.0 ... linking ... done. Loading package hpc-0.6.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-7.6.3 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package hello-0.1.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package exceptions-0.3.3.1 ... linking ... done. Loading package extensible-exceptions-0.1.1.4 ... linking ... done. Loading package ghc-mtl-1.1.0.0 ... linking ... done. Loading package ghc-paths-0.1.0.9 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package hint-0.4.0.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_hellozm0zi1zi0zi0_Hello whilst processing object file /Users/gelisam/.cabal/lib/x86_64-osx- ghc-7.6.3/hello-0.1.0.0/libHShello-0.1.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} A minimal definition for the hello package is attached, but doesn't contain anything relevant to the issue. It's just a dummy datatype: {{{#!haskell {-# LANGUAGE DeriveDataTypeable #-} module Hello where import Data.Typeable data Hello = Hello deriving Typeable }}} === Workaround Use Cabal 1.16, which (also) installs object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable
by GHC 06 Jun '14

06 Jun '14

#9069: -XDeriveTraversable should imply -XDeriveFunctor and -XDeriveFoldable ------------------------------------+------------------------------------- Reporter: sjoerd_visscher | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In the discussion in #2953 it was concluded that it would be best to have separate flags for deriving Functor, Foldable and Traversable. I agree with that conclusion, but it seems that it wasn't considered to have -XDeriveTraversable imply -XDeriveFunctor and -XDeriveFoldable. I can't think of a reason not to want that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling)
by GHC 03 Jun '14

03 Jun '14

#8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ----------------------------------+--------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm configuring and building {{{haskell-src-exts}}} like this: {{{ runhaskell Setup configure -O -p --enable-shared \ -fbase4 runhaskell Setup build }}} It builds the ordinary bits just fine, but when it gets to compiling for profiling: {{{ [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc340_0/ghc340_8.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8475: Library docs: broken links to Foreign.ForeignPtr
by GHC 03 Jun '14

03 Jun '14

#8475: Library docs: broken links to Foreign.ForeignPtr ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Documentation | 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: | ------------------------------------+------------------------------------- In the library docs at `http://www.haskell.org/ghc/docs/latest/html/libraries/index.html`, the `Foreign.ForeignPtr` module in the contents is the one from `haskell2010`, not `base`. This causes various problems, it seems. For instance: * the link from `ForeignPtr` to `Foreign.ForeignPtr` is broken * the link from `Foreign.Concurrent` to `Foreign.ForeignPtr` is broken there are probably other broken links too. We need to figure out what to do about overlapping modules properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8781: check if GNU nm is realy needed and if so let configure detect gnm
by GHC 03 Jun '14

03 Jun '14

#8781: check if GNU nm is realy needed and if so let configure detect gnm ----------------------------------+---------------------------------------- Reporter: maeder | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Solaris Keywords: | Type of failure: Building GHC failed Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- building ghc-7.8.20140130 under Solaris fails with a non-GNU nm as follows: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/opt/csw/bin/gcc" --gcc-flag -U__i686 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc- flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/ccs/bin/nm" Can't find "STD_HDR_SIZE" gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris
by GHC 03 Jun '14

03 Jun '14

#8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris ------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-i386-unknown- solaris2.tar.bz2 has a ghc-pwd-bindist script containing {{{ #!/bin/sh export LD_LIBRARY_PATH="libraries/directory/dist- install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist- install/build:rts/dist/build:$LD_LIBRARY_PATH" exec "utils/ghc-pwd/dist-install/build/tmp/ghc-pwd" ${1+"$@"} }}} that fails during configure under Solaris with: {{{ checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory /dist-install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:: is not an identifier configure: error: cannot determine current directory }}} see more under http://www.haskell.org/pipermail/glasgow-haskell- users/2014-February/024669.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #9001: unexpected runtime crash
by GHC 03 Jun '14

03 Jun '14

#9001: unexpected runtime crash ------------------------------------+------------------------------------- Reporter: jwlato | 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: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Apologies for the poor summary, I'm not sure how to be more descriptive. I don't see anything dodgy here. Compiling the attached program `ghc -O -dcore-lint Test.hs` and running it results in a runtime crash. Various incarnations of this code have resulted in Test: internal error: scavenge_one: strange object 0 Test: internal error: stg_ap_p_ret and core dumps with no further information. I've been able to reproduce this with ghc-7.8.2 and ghc-7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10