September 2016 - ghc-tickets

[GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV
by GHC 24 Sep '16

24 Sep '16

#11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV ----------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 4820 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- on my 4 core macbook pro i can reliably get a sigsev when running the shake test suite with profiling enabled and the RTS flags +RTS -hb -N10 steps to reproduce (with either ghc 7.10.3 or an 8.0 RC4 build) {{{ cabal get --source shake cd shake # shake master was commit f0c0ce8d4c2c017b9a26b5d4258e07d881f4cde1 as of time of testing # but problem should happen with eg 0.15.6 too cabal install # this is so that the shake test suite can fine the right template file cabal install --only-dep --enable-tests --enable-profiling ./dist/build/shake-test/shake-test +RTS -hb -N10 }}} this last command yields the error {{{ ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** fish: './dist/build/shake-test/shake-t…' terminated by signal SIGSEGV (Address boundary error) }}} i can also trigger the bug reported in #4820 by running the test suite with the -hr flag rather than -hb I'm marking this as HIGHEST so it can be discussed, because the profiiling build of the shake test suite only seems to crash *if* the test suite is run with -hb or -hr flags, which seems like a pretty nasty bug (which colleagues have it in other code) nb: `./dist/build/shake-test/shake-test +RTS -N10 ` runs into a not enough stack space error before the shake test suite completes, but `./dist/build/shake-test/shake-test +RTS -K1G -N10 ` seems to work fine, though the crashes happen super early in the gargantuan test suite the analogous output for reproducing #4820 is : {{{ ./dist/build/shake-test/shake-test +RTS -hr -N10 ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** Longest file modification time lag was 1005ms ## BUILD tar test ## TESTING tar ## BUILD tar --abbrev=output=$OUT -j3 Writing report to $OUT/tar/report.html Build completed in 0:01m ## BUILD tar --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/tar/report.html Writing report to - * This database has tracked 1 runs. * There are 4 rules (4 rebuilt in the last run). * Building required 1 traced commands (1 in the last run). * The total (unparallelised) time is 0.01s of which 0.01s is traced commands. * The longest rule takes 0.01s (output/tar/result.tar), and the longest traced command takes 0.01s (tar). * Last run gave an average parallelism of 0.44 times over 0.01s. Build completed in 0:01m ## BUILD tar Writing report to output/tar/report.html Build completed in 0:01m ## FINISHED TESTING tar ## BUILD self test ## TESTING self ## BUILD self --abbrev=output=$OUT -j3 Writing report to $OUT/self/report.html Build completed in 0:01m ## BUILD self --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/self/report.html Writing report to - * This database has tracked 2 runs. * There are 460 rules (2 rebuilt in the last run). * Building required 56 traced commands (1 in the last run). * The total (unparallelised) time is 22.73s of which 22.33s is traced commands. * The longest rule takes 1.11s (output/self/Development/Shake/Types.o output/self/Development/Shake/Types.hi), and the longest traced command takes 1.11s (ghc). * Last run gave an average parallelism of 0.78 times over 0.05s. Build completed in 0:01m ## BUILD self shake-test: internal error: Invalid object in isRetainer(): 39 (GHC version 8.0.0.20160421 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 24 Sep '16

24 Sep '16

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12613: Fix spelling of INLIN(E)ABLE in comments
by GHC 24 Sep '16

24 Sep '16

#12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The correct spelling is `INLINABLE`. It is confusing to read comments which refer to `INLINEABLE`. How to fix this: 1. `git grep INLINEABLE` 2. Open all the files and change to `INLINABLE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7181: Add documentation on heap-profile file format.
by GHC 23 Sep '16

23 Sep '16

#7181: Add documentation on heap-profile file format. -------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.4.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7181#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7181: Add documentation on heap-profile file format.
by GHC 23 Sep '16

23 Sep '16

#7181: Add documentation on heap-profile file format. -------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: We should be able to close this with the 8.2 release as we will support sending heap profiler census data to the eventlog, the encoding of which is documented in the users guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7181#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12611: expression calculation error
by GHC 23 Sep '16

23 Sep '16

#12611: expression calculation error ----------------------------------------+---------------------------- Reporter: Tom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Prelude> 20^65-exp(65*log(20)) 6.211571712111507e70 Obviously, correct result is 0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5402: Exit code is wrong with dynamically loaded libraries
by GHC 23 Sep '16

23 Sep '16

#5402: Exit code is wrong with dynamically loaded libraries -------------------------------------+------------------------------------ Reporter: Lennart | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.2 Component: Runtime System | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: ffi/should_run/5402 Blocked By: | Blocking: -------------------------------------+------------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:"9cbcdb4863064753df0fff9054b7b7c6b3188b64/ghc" 9cbcdb48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cbcdb4863064753df0fff9054b7b7c6b3188b64" shutdownHaskellAndExit: just do a normal hs_exit() (#5402) If we want to keep the RTS alive a bit longer by having another hs_init()/hs_exit() pair in a library that will destruct itself after main() has exited, then the forced shutdown here thwarts that. I think we just "fixed" #5402 in the wrong way before, this should be better. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5402#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone
by GHC 23 Sep '16

23 Sep '16

#12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a `ForeignPtr` `fptr32` with a C finalizer and a `Concurrent.ForeignPtr` with a finalizer that needs to access `fptr32`. Unfortunately, accessing `fptr32` from the concurrent finalizer does not assert that `fptr32` is still alive. Consider the following program: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import qualified Foreign.Concurrent as FC import Foreign.Storable (peek) import Foreign.ForeignPtr (ForeignPtr, withForeignPtr, newForeignPtr) import Foreign.Ptr (Ptr, FunPtr, nullPtr) import Control.Monad (void) import Data.Word (Word32) import System.Mem (performGC) foreign import ccall safe "create" create :: IO (Ptr Word32) foreign import ccall safe "&delete" delete :: FunPtr (Ptr Word32 -> IO ()) makeForeignPtr :: IO () -> IO (ForeignPtr ()) makeForeignPtr final = FC.newForeignPtr nullPtr final finalizer :: ForeignPtr Word32 -> IO () finalizer fptr = do withForeignPtr fptr $ \ptr -> print =<< peek ptr main :: IO () main = do fptr32 <- newForeignPtr delete =<< create void $ makeForeignPtr (finalizer fptr32) performGC }}} and {{{#!c #include "stdio.h" #include "stdlib.h" #include "stdint.h" uint32_t *create () { uint32_t *ptr = malloc(sizeof(uint32_t)); printf ("create %lx\n", (unsigned long int)ptr); *ptr = 23; return ptr; } void delete (uint32_t *ptr) { printf ("delete %lx\n", (unsigned long int)ptr); *ptr = 42; free(ptr); } }}} It emits: {{{ create 2685dc0 delete 2685dc0 0 }}} If it would be correct, it would print `23` instead of `0` and it would print the number before `delete`. Is this a bug or a feature? If it is a feature, how do I get what I need? I know that the documentation says that we must not use `touchForeignPtr` for enforcing a particular order of running finalizers, but I thought that `withForeignPtr`/`touchForeignPtr` pretty clearly state that the `ForeignPtr` must be alive in `finalizer`. I cannot see an abuse here. Actually, this is a simplified version from an example that is even worse: In the original code, `create` is the LLVM-JIT creating code for a finalizer, `delete` frees the function code and `finalizer` runs the LLVM generated finalizer code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11505: Boot file problem
by GHC 21 Sep '16

21 Sep '16

#11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here are two modules and a boot file. Compile by {{{ ghc -c Foo.hs-boot; ghc -c Bar.hs; ghc -c Foo.hs }}} and observe this error message {{{ Foo.hs:12:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: {-# UNPACK #-} !Int} Boot file: data Foo = Foo {x :: !Int} }}} But the definitions are not conflicting, they are identical. Foo.hs-boot: {{{ module Foo where data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Foo.hs: {{{ module Foo where import Bar data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} Removing the unbox pragma gives the even more perplexing: {{{ Foo.hs:3:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: !Int} Boot file: data Foo = Foo {x :: !Int} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6