May 2014 - ghc-tickets

[GHC] #8323: explore ways to possibly use more tag bits in x86_64 pointers
by GHC 28 Nov '14

28 Nov '14

#8323: explore ways to possibly use more tag bits in x86_64 pointers ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | 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: | ------------------------------------+------------------------------------- on x86_64, pointers only use 48 bits! currently we use 3bits for tagging / arity etc info on x86_64, we should explore more uses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
by GHC 28 Nov '14

28 Nov '14

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I am getting segfaults when a statically linked executable uses a GHC API. When the same executable is however dynamically linked it runs without error. In case of the statically-linked version, I think that one of GHC API functions that tries to do dynamic-linking is causing the segfault. The reason why I think this, is because the segfault shows up when Template-Haskell is used, or when {{{ {-# ANN ... #-} }}} annotations are used. An example of this strange behaviour can be shown using haddock, and running it on the source-code for the lens library [1]: {{{ ~/Documents/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGE> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Bus error: 10 <-- SEGFAULT }}} And the GDB output: {{{ (gdb) run -v3 Control/Lens/Internal/ByteString.hs Starting program: /Users/christiaan/.ghc- config/cabal/7.7.20130924/bin/haddock -v3 Control/Lens/Internal/ByteString.hs Reading symbols for shared libraries +++.............................. done Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGES> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000000010828b982 0x000000010828b982 in ?? () }}} I should note that until now I've been unable to produce a _small_ test case that shows the above behaviour. The statically linked haddock actually runs successfully on many packages. The lens[1] package is the first widely used library that I've been able to get haddock to exhibit the above behaviour. Also, when I built a dynamically-linked version of haddock, it runs succesfully for the above test-case (and the other test-cases where the statically-linked version would give a segfault). The source-code for lens[1] contains many {{{ {-# ANN ... #-} }}} annotations; removing all those annotations make the statically-linked version of haddock run successfully, with out segfaults. Halfway through removing the {{{ {-# ANN ... #-} }}} annotation, I also encountered the following error: {{{ Checking module Control.Lens.Fold... haddock: internal error: ARR_WORDS object entered! (GHC version 7.7.20130924 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} I've also encountered the segfault while running the statically-linked haddock on my own clash library [2]. In this case I think it might have something to do with the use of template-haskell. Again, running the dynamically-linked version of haddock does not show any problems. Here is some extra information about my development environment:[[BR]] OS: OS X 10.8.5[[BR]] X-Code: XCode CL-Tools 4.6.2[[BR]] GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546)[[BR]] Output of {{{make show VALUE=GhcLibWays}}}: v dyn[[BR]] build.mk: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO }}} I create statically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{False}}}[[BR]] I create dynamically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{True}}}[[BR]] I created the {{{haddock}}} executables by running {{{cabal install}}} in {{{"up-to-date build tree of GHC"/utils/haddock}}} [1] https://github.com/ekmett/lens[[BR]] [2] http://hackage.haskell.org/package/clash-lib -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8338: Incoherent instances without -XIncoherentInstances
by GHC 25 Nov '14

25 Nov '14

#8338: Incoherent instances without -XIncoherentInstances ------------------------------------+------------------------------------- Reporter: goldfire | 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: | ------------------------------------+------------------------------------- Consider the following 4 modules: {{{ {-# LANGUAGE GADTs #-} module A where data One = One data ShowInstFor a = Show a => MkSIF incoherent :: ShowInstFor One -> ShowInstFor One -> String incoherent MkSIF MkSIF = show One }}} {{{ module B where import A instance Show One where show _ = "from module B" fromB :: ShowInstFor One fromB = MkSIF }}} {{{ module C where import A instance Show One where show _ = "from module C" fromC :: ShowInstFor One fromC = MkSIF }}} {{{ module D where import A import B import C oops1 = incoherent fromB fromC oops2 = incoherent fromC fromB }}} According to ghci, `oops1` is `"from moduleB"` and `oops2` is `"from module C"`. This seems bad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8046: Make the timer management scale better across multicore
by GHC 22 Nov '14

22 Nov '14

#8046: Make the timer management scale better across multicore ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- A recent commit {{{ commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8054: Undefined symbol during linking
by GHC 22 Nov '14

22 Nov '14

#8054: Undefined symbol during linking ------------------------------------+------------------------------------- Reporter: case | 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: | ------------------------------------+------------------------------------- On OSX, using GHC 7.6.3 and the package recursion-schemes 3.0.0.2, the following code causes the compiler to emit an error about undefined symbols. Code: {{{ import Data.Functor.Foldable x = project 1 :: Integer main = x `seq` return () }}} Error: {{{ λ ~/ ghc test.hs Linking test ... Undefined symbols for architecture x86_64: "_Main_x_closure", referenced from: _Main_main_info in test.o _Main_main_srt in test.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8056: Make Install fails on HEAD
by GHC 22 Nov '14

22 Nov '14

#8056: Make Install fails on HEAD ------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm trying to build the `perf` flavor of head and I'm getting an error with `make install`. The `quick` flavor works as expected. {{{ $ uname -a Linux ... 3.6.5-1.fc17.x86_64 ... $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library $ gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) ... $ git clone http://darcs.haskell.org/ghc.git/ ghc-7.8/ ... $ cd ghc-7.8 $ ./sync-all --testsuite get ... $ cp mk/build.mk.sample mk/build.mk $ vi mk/build.mk $ diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf $ perl boot ... $ ./configure --prefix=/localdisk/ryates/ghc-7.8-build/ ... $ make -j8 ... $ make install ... Installing library in /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/haskell2010-1.1.1.0 "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg" --force --global-package-db "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/package.conf.d" update rts/dist/package.conf.install /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg: symbol lookup error: /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin /ghc-pkg: undefined symbol: base_DataziList_intercalatezuzdspolyzugo_info make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8568: internal error: allocation of ... bytes too large
by GHC 21 Nov '14

21 Nov '14

#8568: internal error: allocation of ... bytes too large ------------------------------------+------------------------------------- Reporter: mojojojo | 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: | ------------------------------------+------------------------------------- Running the following GHCi session: {{{ import GHC.DataSize import qualified Data.HashTable.IO as HT import Control.Monad t <- HT.new :: IO (HT.BasicHashTable Int Char) forM_ [0..100000] $ \i -> HT.insert t i 'a' recursiveSize t }}} results in the following error: {{{ <interactive>: internal error: allocation of 1208480 bytes too large (GHC should have complained at compile-time) (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported
by GHC 21 Nov '14

21 Nov '14

#8149: GHC should warn about redundant import of a type name also if one of its record selectors is imported ------------------------------------+------------------------------------- Reporter: Lemming | 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: | ------------------------------------+------------------------------------- Sorry, I have another corner case for a redundant import warning: {{{ module Main where import Control.Monad.Trans.Writer (WriterT, runWriterT) main :: IO () main = undefined runWriterT }}} This module will not provoke a warning, although the import of WriterT can be omitted. I assume this is because runWriterT is a record selector of WriterT and could (or should?) be imported as: {{{ import Control.Monad.Trans.Writer (WriterT(runWriterT)) }}} Since I used runWriterT like a regular function I did not care about its record selector feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8
by GHC 21 Nov '14

21 Nov '14

#8094: Intermittent segfault when using ghc-7.6.3 -e on OSX 10.6.8 ----------------------------------+---------------------------------- Reporter: rampion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- This error was observed using the 64-bit version of ghc-7.6.3 packaged with the Haskell Platform 2013.2.0.0 for OSX. Running commands with `ghc -e` sometimes produces a segfault. {{{ % ghc -e 'return ()' ; echo $? 0 % ghc -e 'return ()' ; echo $? zsh: segmentation fault ghc -e 'return ()' 139 }}} I don't know exactly what's causing it, but I'm suspicious of the binary distributed with the package. When I pull it up in `gdb`, there are warnings pertaining to missing object files expected to be in a `/Users/ian` directory. There's never been an `ian` user on my machine, so I suspect that's an artifact from whomever built the binary. This may also be the root of the intermittent segfault {{{ % cd /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3 % gdb ghc GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done warning: Could not find object file "/Users/ian/zz64/ghc-7.6.3/rts/dist/build/libHSrts_thr.a(darwin64.o)" - no debug information available for "/var/folders/9z/yntzqjqn1j95xbpb6dr3qbww0000gn/T//ccr2b8iU.s". warning: Could not find object file "/Users/ian/zz64/ghc-7.6.3/rts/dist/build/libHSrts_thr.a(ffi64.o)" - no debug information available for "../src/x86/ffi64.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.6.3/rts/dist/build/libHSrts_thr.a(prep_cif.o)" - no debug information available for "../src/prep_cif.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.6.3/rts/dist/build/libHSrts_thr.a(types.o)" - no debug information available for "../src/types.c". (gdb) run -B. -e 'return ()' Starting program: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/ghc -B. -e 'return ()' Reading symbols for shared libraries + done Program exited normally. (gdb) run -B. -e 'return ()' Starting program: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/ghc -B. -e 'return ()' Reading symbols for shared libraries + done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000f34ed440 0x00000001f34d659a in evacuate1 () (gdb) where #0 0x00000001f34d659a in evacuate1 () #1 0x00000001f34dc1b8 in scavenge_block1 () Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) kill Kill the program being debugged? (y or n) y error while killing target (killing anyway): assertion failure on line 300 of "/SourceCache/gdb/gdb-1518/src/gdb/macosx/macosx-nat-inferior-util.c" in function "macosx_inferior_suspend_ptrace": status.value.sig == TARGET_SIGNAL_STOP warning: error on line 2182 of "/SourceCache/gdb/gdb-1518/src/gdb/macosx /macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x) (gdb) run -B. -e '()' Starting program: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/ghc -B. -e '()' Reading symbols for shared libraries + done () Program exited normally. (gdb) run -B. -e '()' Starting program: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/ghc -B. -e '()' Reading symbols for shared libraries + done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000d1916440 [Switching to process 18462 thread 0x2003] 0x00000001d191bc44 in stg_ap_v_fast () (gdb) where #0 0x00000001d191bc44 in stg_ap_v_fast () #1 0x0000000000000000 in ?? () (gdb) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8