August 2016 - ghc-tickets

[GHC] #11054: GHC on Windows could not use more than 64 logical processors
by GHC 04 Oct '16

04 Oct '16

#11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_proc… MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #11987: Allow record wildcards with pattern synonyms
by GHC 02 Oct '16

02 Oct '16

#11987: Allow record wildcards with pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With pattern synonym `pattern Point {x, y} = (x, y)` we can write {{{ >>> let { x = 1; y = 2 } in Point { x = x, y = y } (1, 2) }}} {{{ >>> let { x = 1; y = 2 } in Point { x, y } (1, 2) }}} but record wildcards ain't workin {{{#!hs >>> let { x = 1; y = 2 } in Point {..} <interactive>:342:25-36: error: Pattern synonym ‘Point’ used as a data constructor }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11792: Optimised unsafe FFI call can get wrong argument
by GHC 02 Oct '16

02 Oct '16

#11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attached a simple test case. It should print 7457, but the C function is called with 0 as the third argument. If I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should. In gdb disassembly looks to me as edx (the place for third argument on 64-bit) is set to 7457, then the opaquify is inlined, but it doesn't preserve edx and then third_arg is called with the zeroed edx. ---------------- Specs ------------- 64-bit Archlinux with arch-haskell repo gcc -v: {{{ Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto- wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with- bugurl=https://bugs.archlinux.org/ --enable- languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable- threads=posix --enable-libmpx --with-system-zlib --with-isl --enable- __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install- libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) }}} ghc compile output: {{{ Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-7.10.3/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Main.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-04-05 14:24:20.801997492 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import Data.Word] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Main.hs Created temporary directory: /tmp/ghc1541_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 317, types: 387, coercions: 3} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 261, types: 290, coercions: 14} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 274, types: 305, coercions: 18} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 407, types: 388, coercions: 70} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 463, types: 375, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 430, types: 362, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 310, types: 291, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 248, types: 217, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Float inwards: Result size of Float inwards = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Float inwards: *** Called arity analysis: Result size of Called arity analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Called arity analysis: *** Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 369, types: 283, coercions: 25} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Tidy Core: writeBinIface: 18 Names writeBinIface: 81 dict entries *** CorePrep: Result size of CorePrep = {terms: 654, types: 379, coercions: 25} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeGen: *** Assembler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler -c /tmp/ghc1541_0/ghc_2.s -o Main.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_3.c /tmp/ghc1541_0/ghc_2.s /tmp/ghc1541_0/ghc_1.s Warning: deleting non-existent /tmp/ghc1541_0/ghc_3.c Warning: deleting non-existent /tmp/ghc1541_0/ghc_1.s link: linkables are ... LinkableM (2016-04-05 15:42:11.288210053 UTC) Main [DotO Main.o] Linking Main ... *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_4.c -o /tmp/ghc1541_0/ghc_5.o -I/usr/lib/ghc-7.10.3/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_7.s -o /tmp/ghc1541_0/ghc_8.o -I/usr/lib/ghc-7.10.3/include *** Linker: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash- size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o Main Main.o Test.o -L/usr/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc-7.10.3/rts /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_8.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger- gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl link: done *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_10.rsp /tmp/ghc1541_0/ghc_9.rsp /tmp/ghc1541_0/ghc_8.o /tmp/ghc1541_0/ghc_7.s /tmp/ghc1541_0/ghc_6.rsp /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_4.c *** Deleting temp dirs: Deleting: /tmp/ghc1541_0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods
by GHC 02 Oct '16

02 Oct '16

#12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 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: -------------------------------------+------------------------------------- The rendered haddock for the {{{Eq}}} and {{{Ord}}} classes are missing: * Their class methods * Their source links See: * http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Eq.html#t:Eq * http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq * http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Ord.html#t:Ord * http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Ord Other (deriviable) classes, for example {{{Show}}}, or {{{Enum}}}, do not have these problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12487: configure.ac uses wrong triple information.
by GHC 02 Oct '16

02 Oct '16

#12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's `configure` script seems to normalize the values returned from `config.guess`. So for Windows it turns `x86_64-pc-mingw64` into `x86_64-unknown-mingw32`. These mangled names are stored in the values `$BuildPlatform`, `$HostPlatform` and `$TargetPlatform`. However further down the file when the comparison is done between the stage0 compiler and the host the normalized versions are not used. So when normalization actually changes the triple this check will fail. Not sure why it's worked for all this time.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12186: GHC compiled executable incompatible with 3rd party software
by GHC 02 Oct '16

02 Oct '16

#12186: GHC compiled executable incompatible with 3rd party software -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces. I've managed to reduce a test case to not actually depend on using Haskell, but just using GHC to compile a C file, and that C file being nothing but a dumb wrapper around a small dll. The resulting executable exhibits the incorrect behaviour: {{{ > stack exec ghc -- main.c -no-hs-main > main 1 2 3 4 5 6 ICLRRuntimeHost Start failed w/hr 0x80004005 }}} Then I can also use GCC on the intermediate object file that was created, and produce an executable that exhibits the correct behaviour: {{{ > stack exec gcc -- main.o -o main2.exe > main2 1 2 3 4 5 6 7 8 }}} I've put a copy of the test case here: https://gitlab.com/tim-m89/DotNetHostingTest -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits
by GHC 02 Oct '16

02 Oct '16

#8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12019: Profiling option -hb is not thread safe
by GHC 02 Oct '16

02 Oct '16

#12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11978, #12009 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is a continuation of #11978 and #12009. After fixing a couple of issues in those two tickets I found that the profiling run time is not thread safe. Have a trivial test program (written as one of the tests for #11978): {{{ import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import Control.Monad main :: IO () main = do putStrLn "Start ..." mvar <- newMVar (0 :: Int) let count = 50 forM_ [ 1 .. count ] $ const $ forkIO $ do threadDelay 100 i <- takeMVar mvar putMVar mvar $! i + 1 threadDelay 1000000 end <- takeMVar mvar putStrLn $ "Final result " ++ show end assert (end == count) $ return () }}} Compiling that with a compiler that has bug fixes arising from #11978 and #12009 as: {{{ inplace/bin/ghc-stage2 testsuite/tests/profiling/should_run/T11978b.hs \ -fforce-recomp -rtsopts -fno-warn-tabs -O -prof -static -auto-all \ -threaded -debug -o T11978b }}} and run as: {{{ ./T11978b +RTS -p -hb -N10 }}} crashes in a number of different ways. I've seen at least 3 different assertion failures and numerous segfaults (in different `stg_ap_*` functions). Replace `-hb` with other profiling options like `-hr` etc do not seem to crash. Looking at code, one example of lack of thread safetly is the function `LDV_recordDead` which mutates global variable `censuses` which does not have any locking around it. Only figured this out because the following assert (in `LDV_recordDead`) was being triggered occasionally. {{{ ASSERT(censuses[t].void_total < censuses[t].not_used); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree
by GHC 30 Sep '16

30 Sep '16

#10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently we have several subsystems independently tracking allocations. It is very likely there are discrepancies between them. Ensuring that they agree would be a great way to test each of them (especially ticky, which is almost certainly bitrotted, see #10739). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9520: Running an action twice uses much more memory than running it once
by GHC 29 Sep '16

29 Sep '16

#9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17