January 2018 - ghc-tickets

[GHC] #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc
by GHC 05 Jan '19

05 Jan '19

#11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: c++ | Operating System: Unknown/Multiple exceptions | Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the C++ program {{{ // Main_cc.cc #include <iostream> #include <exception> extern "C" { int func() { try { throw std::runtime_error("THIS FAILS!"); } catch(const std::runtime_error &c) { std::cerr << c.what(); } return 0; } } }}} and the Haskell program {{{#!hs -- Main.hs module Main where import Foreign.C.Types foreign import ccall func :: IO CInt main :: IO () main = print =<< func }}} When compiled with {{{ ghc --make Main.hs Main_cc.cc -lstdc++ }}} and being run on mac os x 10.11.3 the result is {{{ libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: THIS FAILS! Abort trap: 6 }}} and not (as it should be): {{{ THIS FAILS!0 }}} When compiled in a similar way under windows some c++ exceptions of a larger project are not caught as well. However, these were hard to track down and I was unable to construct a simple example like the one above. As a workaround one can * write a main() function in c++ and call from there into Haskell, * compile the Haskell-Module with the options "-c -no-hs-main", and * link the application using g++ (not ghc!). When being compiled / linked this way, all c++ exceptions are being caught in mac os x as well as under windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13630: ByteString pinned memory can be leaky
by GHC 04 Jan '19

04 Jan '19

#13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) 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: -------------------------------------+------------------------------------- My question on IRC: {{{ How does memory allocation for pinned blocks work? Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB ByteString A and then an 8-byte ByteString B. Now I GC A, no longer need it. Then according to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned "a single pinned object keeps alive the whole block in which it resides", my small ByteString B keeps the entire block alive. But what happens with the 3KB in the front of that block? Will it be re-used by the next ByteString allocation (say 1KB)? In other words, how smart is allocatePinned as an allocator? }}} The answer: {{{ slyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space }}} {{{ nh2: slyfox: that sounds like a huge potential for memory leak then slyfox: yes, fragmentation is quite bad for bytestrings }}} So it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak. One idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions. However, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case. Efficient here means, for example, to re-use freed memory inside a block instead of only using free tail space. It seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them: https://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared- memory Perhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11962: Support induction recursion
by GHC 04 Jan '19

04 Jan '19

#11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Now that we have `-XTypeInType`, let's take it a step further and allow induction recursion. This feature exists in Agda and Idris. Here is a short example of what can be done in Agda: {{{ mutual -- Codes for types. data U : Set where nat : U pi : (a : U) → (El a → U) → U -- A function that interprets codes as actual types. El : U → Set El nat = ℕ El (pi a b) = (x : El a) → El (b x) }}} Note that the `U` datatype and the `El` function depend on each other. But if you look more closely, the header for `U` does not depend on `El`; only the constructors of `U` depend on `El`. So if we typecheck `U : Set` first, then `El : U → Set`, then the constructors of `U`, then the equations of `El`, we're OK. Translation into Haskell: {{{ import Data.Kind data family Sing (a :: k) -- we still require singletons data U :: Type where Nat :: U Pi :: Sing (a :: U) -> (El a -> U) -> U type family El (u :: U) :: Type where El 'Nat = Int El (Pi a b) = forall (x :: El a). Sing x -> El (b x) }}} This currently errors with {{{ • Type constructor ‘U’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘U’ }}} It needn't error. (I'm cheating a bit here, because for unrelated reasons, we can't return a `forall` on the right-hand side of a type family. But that's not the issue at hand.) I have some very sketchy notes on how we might do this [wiki:DependentHaskell/Internal#Separatingtypesignaturesfromdefinitions here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler.
by GHC 28 Dec '18

28 Dec '18

#14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- For simple code such as `if a > 10 then foo else bar` it can make a big difference if we jump on `a > 10` or `a <= 10`. We already tracked the likelyhood of such conditionals for stack/heap checks in Cmm. I recently updated the native codegen on X86 to take this information into account where available and in one edge case this improved execution time from 1.7s to 1.5s! Having this info available for other cases like bound checking (assume valid) or partial pattern matches (assume no match failure) should be a small win for most programs and hopefully a big one for a few of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14375: Implement with# primop
by GHC 27 Dec '18

27 Dec '18

#14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | 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): Phab:D4110 | Wiki Page: -------------------------------------+------------------------------------- In Trac #14346 we proposed the new `with#` primop {{{ with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See Phab:D4110. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer
by GHC 26 Dec '18

26 Dec '18

#12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: backpack | 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 don't think this is a very harmful bug but it definitely is a bug. Consider: {{{ -- A.hs-boot module A where data T -- B.hs module B (module A) where import {-# SOURCE #-} A -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where import qualified B import Language.Haskell.TH f :: B.T -> B.T f x = x $( return [] ) data T = T B.T }}} The point of the splice is to convince GHC to typecheck `f :: B.T -> B.T` before it typechecks the type declaration. But this is not going to work, because `tcLookupGlobal` is going to bail if (1) T is not in the `tcg_type_env` and (2) T comes from this module. It would be a simple matter to improve the error message but from a user's perspective, there is no good reason for this to not typecheck. On the implementation side, I am sympathetic to not letting this typecheck: if it does typecheck, then some `TyCon`s will incorrectly refer to the definition from the hs-boot file, rather than our local definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc)
by GHC 25 Dec '18

25 Dec '18

#11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: perf/space_leaks/space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{ import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9627: Type error with functional dependencies
by GHC 24 Dec '18

24 Dec '18

#9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached file should compile. The types T1, T2, and T3 are all equivalent types (T1 and T2 normalize to T3), but with foo::T1 and bar::T2 there is a type error. Rewriting the example using type families instead of FD makes it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4