April 2018 - ghc-tickets

[GHC] #14834: Executable have problems with DWARF debug information
by GHC 04 Mar '19

04 Mar '19

#14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64). A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster. We used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23] In response, the tool author brought us back a output of a problem in objdump tool over our executable: {{{ c:\tmp\cv\crash>C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14494: TBQueue leaks space under certain workloads
by GHC 03 Mar '19

03 Mar '19

#14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Keywords: stm | 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'm using TBQueue and I noticed suspiciously high memory usage, so I decided to profile and it turned out that readTBQueue leaks space (see attached before.png). After closer inspection it turned out it's the `writeTVar rsize (r + 1)` in readTBQueue definition that's the problem - after substitution it for `writeTVar rsize $! r + 1` the leak is gone (see attached after.png) Here are -s outputs: Before: {{{ 366,535,518,024 bytes allocated in the heap 115,643,281,224 bytes copied during GC 241,356,416 bytes maximum residency (1182 sample(s)) 1,516,944 bytes maximum slop 392 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 247273 colls, 247273 par 128.854s 28.654s 0.0001s 0.0182s Gen 1 1182 colls, 1181 par 352.162s 87.812s 0.0743s 0.1322s Parallel GC work balance: 78.17% (serial 0%, perfect 100%) TASKS: 24 (1 bound, 16 peak workers (23 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.003s ( 0.003s elapsed) MUT time 581.754s (226.191s elapsed) GC time 317.130s ( 75.533s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 163.885s ( 40.933s elapsed) EXIT time 0.013s ( 0.011s elapsed) Total time 1062.789s (301.738s elapsed) Alloc rate 630,052,684 bytes per MUT second Productivity 54.7% of total user, 61.4% of total elapsed gc_alloc_block_sync: 8998531 whitehole_spin: 96 gen[0].sync: 180553 gen[1].sync: 31648044 }}} After: {{{ 431,671,260,464 bytes allocated in the heap 86,540,207,400 bytes copied during GC 170,338,336 bytes maximum residency (1381 sample(s)) 1,159,472 bytes maximum slop 260 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 290179 colls, 290179 par 148.921s 33.097s 0.0001s 0.0217s Gen 1 1381 colls, 1380 par 206.679s 51.492s 0.0373s 0.0528s Parallel GC work balance: 75.51% (serial 0%, perfect 100%) TASKS: 23 (1 bound, 17 peak workers (22 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.005s ( 0.004s elapsed) MUT time 681.718s (241.009s elapsed) GC time 258.643s ( 60.370s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 96.957s ( 24.219s elapsed) EXIT time 0.009s ( 0.007s elapsed) Total time 1037.335s (301.390s elapsed) Alloc rate 633,210,748 bytes per MUT second Productivity 65.7% of total user, 71.9% of total elapsed gc_alloc_block_sync: 5494680 whitehole_spin: 184 gen[0].sync: 184109 gen[1].sync: 24223953 }}} Attached patch fixes the problem (I made all Int increments/decrements in the module strict as there is no need for them to be lazy). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10841: Run handler on STM retry
by GHC 03 Mar '19

03 Mar '19

#10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be nice to have a function like: {{{#!hs -- | Perform a series of STM actions atomically. -- -- Whenever the transaction retries, run the handler. If it doesn't return 'Nothing', -- stop the retrying and return the value given by the handler. atomicallyWithRetryHandler :: STM a -> IO (Maybe a) -> IO a }}} This would allow tracking retry statistics, printing debug messages on each retry, etc. without resorting to unsafeIOToSTM which can't safely do things like printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13002: :set -O does not work in .ghci file
by GHC 03 Mar '19

03 Mar '19

#13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2
by GHC 03 Mar '19

03 Mar '19

#12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From IRC: I have a module that takes around 10 seconds to compile on ghc --make -O2, but only around 3 seconds on ghci -fobject-code -O2. > bgamari: that is surprising I've put the -v timing output of the two cases into https://gist.github.com/nh2/e9bc4732111bfe422d8e606c10f8f0ac I'm comparing the 2 files with `meld` for spotting differences easily. Check e.g. `Result size of Tidy Core` which seems to have 3x as many terms for ghc, and `Simplifier [Mymodule]` doesn't seem to run in ghci The first time terms are different is at `Desugar, the first time a factor 3 comes in is after `Specialize`. > bgamari: wow, it sounds like the simplifier isn't getting run as aggressively in GHCi I'm running this on Ubuntu 16.04 inside nix (but happens the same way outside nix). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14069: RTS linker maps code as writable
by GHC 02 Mar '19

02 Mar '19

#14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- GHC's RTS linker maps executable code in writable pages, representing a significant potential exploit point for arbitrary code execution. OpenBSD disallows running program that do this by default. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11503: TypeError woes (incl. pattern match checker)
by GHC 01 Mar '19

01 Mar '19

#11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeFamilies, UndecidableInstances #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module Bug where import GHC.TypeLits import GHC.Exts ( Constraint ) type family NotInt a where NotInt Int = TypeError (Text "That's Int, silly.") NotInt _ = (() :: Constraint) data T a where MkT1 :: a -> T a MkT2 :: NotInt a => T a foo :: T Int -> Int foo (MkT1 x) = x }}} I get {{{ Bug.hs:19:1: warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: MkT2 }}} But I shouldn't. Even worse, perhaps, GHC accepts my pattern-match against `MkT2` if I add it. If I change the `TypeError` to `False ~ True`, I get the correct behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14109: GHC matches -- as a varsym when lexing a qvarsym
by GHC 28 Feb '19

28 Feb '19

#14109: GHC matches -- as a varsym when lexing a qvarsym -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems only to exclude the line comment marker `--` when lexing a varsym and not a qvarsym. This can be observed in the following code {{{ module Demo where x Demo.-- y = (x,y) }}} Generating this surprising error message {{{ /Users/emertens/Desktop/Demo.hs:3:3: error: Qualified name in binding position: Demo.-- }}} and excludes this definition perhaps? {{{ example f = Just.-- comment f }}} Which might either have lexed as `Just` `.` `-- comment`, or it might have lexed as `Just.-` `-`, but it probably shouldn't be the case that it's a qvarsym. At a minimum, the Haskell Report specifically excludes `--` from the varsym rule, so it can't support the qvarsym rule match that it is now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9121: Presence of dyn_o files not checked? upon recompilation
by GHC 28 Feb '19

28 Feb '19

#9121: Presence of dyn_o files not checked? upon recompilation ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14419: Check kinds for ambiguity
by GHC 27 Feb '19

27 Feb '19

#14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- GHC does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected: {{{#!hs type family F a data T :: F a -> Type }}} `T`'s kind is ambiguous, and any occurrence of `T` will be rejected. Instead of rejecting usage sites, let's just reject the definition site. This check would be disabled by `AllowAmbiguousTypes`. Happily, I think the implementation should be easy, and that the current algorithm to check for ambiguous types should work for kinds, too. After all, types and kinds are the same these days. This was inspired by #14203, but no need to read that ticket to understand this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14