March 2013 - ghc-tickets

[GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash
by GHC 13 Apr '13

13 Apr '13

#7767: "internal error: evacuate: strange closure type 154886248" crash --------------------------+------------------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I have a simple Main.hs that uses the GHC API to produce a '''ParsedModule'''. I then use ghc-vis this value, which is when I get: {{{ Starting ... Setting dynamic flags ... Guessing and adding target ... Analyze dependencies ... Getting module summary ... Parsing module ... Main: internal error: evacuate: strange closure type 154886248 (GHC version 7.6.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 7583 abort ./Main }}} Here is the Main.hs: {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE RecordWildCards #-} {- See the following link for additional details about the API: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API -} module Main where import Module import RdrName import OccName import BasicTypes --import Bag --import HsDecls --import Control.Monad import Control.Exception (throw) import GHC hiding (loadModule) import SrcLoc import MonadUtils import GHC.Paths (libdir) import HscTypes --import DynFlags import Unsafe.Coerce --import Bag (bagToList) --import Outputable --import Name import Data.Typeable import Text.Show import Data.Foldable(forM_) import GHC.Exts --import GHC.HeapView import GHC.Vis main :: IO () main = do doMain getLine return () --libdir = "/Library/Frameworks/GHC.framework/Versions/7.6.2-x86_64/usr/lib" doMain = do putStrLn "Starting ..." runGhc (Just libdir) $ do -- liftIO $ putStrLn "Setting dynamic flags ..." dflags <- getSessionDynFlags setSessionDynFlags (dflags) -- liftIO $ putStrLn "Guessing and adding target ..." -- guessTarget :: GhcMonad m => String -> Maybe Phase -> m Target target <- guessTarget "Test.hs" Nothing -- addTarget :: GhcMonad m => Target -> m () addTarget target --liftIO $ putStrLn "Loading all targets ..." --_ <- load (LoadUpTo modName) liftIO $ putStrLn "Analyze dependencies ..." -- depanal :: GhcMonad m => -- [ModuleName] -- ^ excluded modules -- -> Bool -- ^ allow duplicate roots -- -> m ModuleGraph modGraph <- depanal [] False let modName = mkModuleName "Test" liftIO $ putStrLn "Getting module summary ..." -- getModSummary :: GhcMonad m => ModuleName -> m ModSummary modSummary <- getModSummary modName liftIO $ putStrLn "Parsing module ..." --data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary -- , pm_parsed_source :: ParsedSource -- , pm_extra_src_files :: [FilePath] } -- type ParsedSource = Located (HsModule RdrName) -- type Located e = GenLocated SrcSpan e -- parseModule :: GhcMonad m => ModSummary -> m ParsedModule parsedMod <- parseModule modSummary liftIO $ vis liftIO $ view parsedMod "parsedMod" --let parsedSrc = pm_parsed_source parsedMod ----walkLocSource parsedSrc ----typecheckModule :: GhcMonad m => ParsedModule -> m TypecheckedModule --liftIO $ putStrLn "Type checking module ..." --typedMod <- typecheckModule parsedMod ----let parsedMod = tm_parsed_module typedMod ----walkLocSource (pm_parsed_source parsedMod) --let rnSource = tm_renamed_source typedMod ----walkRenamedSource rnSource ---- desugarModule :: GhcMonad m => TypecheckedModule -> m DesugaredModule --liftIO $ putStrLn "Desugaring module ..." --desugaredMod <- desugarModule typedMod return () }}} I have built it using: {{{ ghc --make -L/usr/lib -package ghc Main.hs -threaded }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7765: Odd error message for `runghc` with missing `main` function.
by GHC 13 Apr '13

13 Apr '13

#7765: Odd error message for `runghc` with missing `main` function. -----------------------------+---------------------------------------------- Reporter: isaacdupree | 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: -----------------------------+---------------------------------------------- {{{ % cat what.hs module Main where {} % runghc what.hs what.hs:1:33: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) }}} '`ghc what.hs`' gives a rather more sensible message. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7762: internal error: evacuate(static): strange closure type 4
by GHC 13 Apr '13

13 Apr '13

#7762: internal error: evacuate(static): strange closure type 4 --------------------------+------------------------------------------------- Reporter: rthiemann | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.0.4 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- resample: internal error: evacuate(static): strange closure type 4 (GHC version 7.0.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Bug occurs reproducable after running the main program for around 8 minutes and consuming 25 GB of RAM. ghc -rtsopts --make Main -o main ./main +RTS -K3000m -RTS > someFile.txt -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7753: Profiling report broken with foreign exported functions
by GHC 13 Apr '13

13 Apr '13

#7753: Profiling report broken with foreign exported functions -------------------------+-------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 7.6.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Save the following Haskell source as wrapper.hs: {{{ import Foreign.Ptr import Control.Monad main = do fptr <- wrap wrapped replicateM 100 $ (return$!) =<< dyn fptr 4 wrapped :: Double -> IO Double wrapped x = return $ f 10000 x f :: Int -> Double -> Double f 0 u = u f n u = (u / fromIntegral n) * f (n-1) u foreign import ccall "wrapper" wrap :: (Double -> IO Double) -> IO (FunPtr (Double -> IO Double)) foreign import ccall "dynamic" dyn :: FunPtr (Double -> IO Double) -> Double -> IO Double }}} Then compile and run it with: {{{ $ ghc -O2 wrapper.hs -fprof-auto -prof $ ./wrapper +RTS -p }}} It generates wrapper.prof (attached). The file contains the following lines: {{{ CAF GHC.IO.Encoding.Iconv 58 0 0.0 0.2 0.0 0.2 wrapped Main 80 100 0.0 1.1 0.0 0.0 f Main 81 1000100 100.0 0.0 0.0 0.0 }}} I see two problems here, (1) the inherited column is 0 for 'wrapped' and 'f' but this is incorrect, and (2) 'wrapped' and 'f' belongs to the wrong cost center, 'GHC.IO.Encoding.Iconv'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7752: GHC as a library documentation out of sync
by GHC 13 Apr '13

13 Apr '13

#7752: GHC as a library documentation out of sync -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The example program(s) at http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc- as-a-library.html no longer compile. The docs probably just need a bit of tweaking. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7751: Incremental heap census
by GHC 13 Apr '13

13 Apr '13

#7751: Incremental heap census -----------------------------+---------------------------------------------- Reporter: ezyang | 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: -----------------------------+---------------------------------------------- At the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out heap census on portions of the heap which were *immediately* GC'd; i.e. an incremental census. The question, then, is how do we reconstruct full heap state from only a partial census? In particular, how do we know if an object that was previously present got collected or got promoted? If we always assume that it got collected (the naive implementation), a promoted object will disappear from the census, and only mysteriously reappear when we do a full census. The trick we want to employ is to save the starting pointer of all of the generations: while the entire generation is not slop free, the remainder of the first block and all of the later blocks are. I believe this is sufficient to reconstruct full heap state. #4225 has related discussion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7746: Support loading/unloading profiled objects from a profiled executable
by GHC 13 Apr '13

13 Apr '13

#7746: Support loading/unloading profiled objects from a profiled executable -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang 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: -----------------------------+---------------------------------------------- This is closely related to #3360, but it is a bit less ambitious and should be possible to implement without too many extra changes to the byte code compiler and interpreter (e.g. we just have to teach the linker how to handle things). Here is a simple test program off of 'plugins' to get working: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Plugins.Make import System.Plugins.Load import Data.List boot :: FilePath -> IO () boot path = do r <- make path ["-prof"] case r of MakeSuccess _ p -> do r' <- load p [] [] "result" case r' of LoadSuccess _ (v :: Int) -> print v LoadFailure msg -> print msg MakeFailure es -> putStrLn ("Failed: " ++ intercalate " " es) main = do boot "Foo.hs" }}} where Foo.hs is {{{ module Foo where result = 2 :: Int }}} Here are the things that, as far as I can tell, need to be handled: * We should ensure consistency between the host and the object file being uploaded. For example, if you load an un-profiled object file into a profiled binary, GHC will eat all your puppies. A simple way to do this is look for a symbol (e.g. CC_LIST) which is only ever exported when something is profiled and barf it is encountered. * This current code fails with {{{test: Foo.o: unknown symbol `CC_LIST'}}}, much the same way GHCi used to fail. This particular problem is (I think) that we don’t store CC_LIST and other externsymbols in our global hash table, so the linker thinks that they don’t exist, when they do. CC_LIST and friends should be special-cased or added to the table. * We don’t run ctors which setup CC_LIST with all of the cost-centres from the loaded module; we need to teach the linker to do that (that's the {{{/* ignore constructor section for now */}}}) * We need to come up with some sensible way of unloading cost-centres from CC_LIST and friends; we could make CC_LIST doubly-linked and then just excise the cost-centre in a destructor, but freeing the actual allocated CostCentre is more difficult. For now, we might just live with the memory leak, but see wiki:"Commentary/ResourceLimits#Memoryleaks" for a possible better implementation strategy. But that’s it; everything else should work normally. Something similar should apply to ticky builds. Something we will have to think about is how to handle these special-cases as we move from static objects to dynamic objects and push more of the runtime linking burden to the standard libraries. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 13 Apr '13

13 Apr '13

#7741: Add SIMD support to x86/x86_64 NCG -----------------------------+---------------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #3557 -----------------------------+---------------------------------------------- ghc-7.7.20130301 has SIMD support. But only LLVM backend supports SIMD currently. If we want to use SIMD, we should use LLVM backend. I request to add SIMD support to x86/x86_64 NCG. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP)
by GHC 13 Apr '13

13 Apr '13

#7736: Parallel array enumeration causes compiler panic (enumFromToP) -------------------------------+-------------------------------------------- Reporter: amosrobinson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Enumeration doesn't work in parallel array comprehensions: {{{ nums = [: 0 .. 100 :] }}} causes a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense: {{{ other = 5 / "bad" nums = [: 0 .. 100 :] }}} it still panics. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7735: -fext-core doesn't generate .hcr when .o and .hi files are present
by GHC 13 Apr '13

13 Apr '13

#7735: -fext-core doesn't generate .hcr when .o and .hi files are present ------------------------------------+--------------------------------------- Reporter: kmels | Owner: Type: bug | Status: new Priority: normal | Component: External Core Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Create a file inside a directory and compile it using -fext-core: {{{ cd /tmp/ mkdir dir echo "module Main where main = return ()" > dir/Main.hs ghc --make -fext-core dir/Main.hs [1 of 1] Compiling Main ( dir/Main.hs, dir/Main.o ) Linking dir/Main ... kmels@kmels-workstelle /tmp $ ls dir/ Main Main.hcr Main.hi Main.hs Main.o }}} If the .hcr file is deleted and our program is compiled again with -fext- core, no .hcr file will be generated: {{{ rm dir/Main.hcr ghc --make -fext-core dir/Main.hs ls dir/ Main Main.hi Main.hs Main.o }}} The file is generated if you 1. cd to dir/ and 2. ghc --make -fext-core Main.hs -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1