http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43467 <pre>#7934: usleep hangs, no threads ----------------------------------------+----------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: 1156 ----------------------------------------+----------------------------------- import System.Posix.Unistd main = flip mapM_ [0..] $ \i -&gt; do usleep 100000 print i === The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print). The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any. The problem also occurs with nanosleep, but not with threadDelay. #1156 sounds related, but this time the problem also occurs without -threaded. === workaround: use threadDelay. </pre> GHC 2013-05-25T22:37:40 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43464 <pre>#7933: JavaScript Cmm backend -----------------------------+---------------------------------------------- Reporter: bosu | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to RFC on the attached patch implementing JavaScript Cmm backend for GHC. It adds -fjavascript compilation option. Calling ghc -fjavascript produces JS in the output file. Otherwise the ghc binary should be fully functional as a native compiler. Thus -fjavascript is similar to -fllvm in spirit. The patch adds HscJavaScript constructor to HscTarget. It is used to dispatch code output to the new JsCodeGen module. Generated JavaScript code relies on the built-in JS garbage collection. JsTransforms module disables GHC Hp and Sp overflow checks. As JavaScript has no pointers, we emulate them using JS closures containing arrays and indices. To distinguish between pointers and scalars we run Hoopl heuristics in PointerMarker module. As in native world, the generated JS object files are to be linked. In order to do this, there is another project, tentatively called Josh[1]. Josh is regular cabalized Haskell binary which links JS object files using function maps provided by GHC. The JavaScript RTS has rts/*.cmm compiled to JavaScript almost as is. In addition there is a handful of handwritten JS code residing in Josh distribution[2]. ghc-prim[3], integer-gmp[4] and base[5] are compiled with small changes. Those changes seem to be orthogonal to the GHC patch. For bootstrap process please see Josh README at github. Josh also includes several tests which work on 32-bit Debian Wheezy. Generated code is in order of 2 MB uncompressed and un-minified. Most of it is in RTS. It compresses very well though (to 150Kb approx). Plenty of low-hanging fruit optimizations are possible. There are plenty caveats to the current patch. It works on 32 bits only. Math is fishy and Integer support is nonexistant. Lots of tests should be imported from GHC, GHCJS, Fay. No Handle based IO works at the moment. No performance tests were done. Despite its shortcomings, the patch is fairly non-invasive, IMHO. It should be noted, that the same approach could work for other GC based platforms (e.g. Java, C#). I'd like to continue working towards merging the patch into GHC, if possible. Could GHC committers provide any guidance of what should be done in order to merge it? [1] https://github.com/bosu/josh [2] https://github.com/bosu/josh/blob/master/etc/ptr.js [3] https://github.com/bosu/ghc-prim [4] https://github.com/bosu/integer-gmp [5] https://github.com/bosu/base </pre> GHC 2013-05-25T13:15:03 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43455 <pre>#7932: haskell-src-exts should depend on happy -----------------------+---------------------------------------------------- Reporter: JasonGross | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 7.4.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- cabal-dev install haskell-src-exts-1.13.5 fails with a missing happy: $ cabal-dev install haskell-src-exts-1.13.5 Resolving dependencies... [1 of 1] Compiling Main ( /tmp/haskell-src-exts-1.13.5-24348 /haskell-src-exts-1.13.5/Setup.hs, /tmp/haskell-src-exts-1.13.5-24348 /haskell-src-ext s-1.13.5/dist/setup/Main.o ) /tmp/haskell-src-exts-1.13.5-24348/haskell-src-exts-1.13.5/Setup.hs:1:1: Warning: In the use of `runTests' (imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks): Deprecated: "Please use the new testing interface instead!" Linking /tmp/haskell-src-exts-1.13.5-24348/haskell-src- exts-1.13.5/dist/setup/setup ... Configuring haskell-src-exts-1.13.5... setup: The program happy version &gt;=1.17 is required but it could not be found. Failed to install haskell-src-exts-1.13.5 cabal: Error: some packages failed to install: haskell-src-exts-1.13.5 failed during the configure step. The exception was: ExitFailure 1 </pre> GHC 2013-05-25T04:09:10 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43452 <pre>#7931: Deriving Read of an empty datatype crashes -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Standalone deriving Read of an empty datatype crashes: {{{ {-# LANGUAGE StandaloneDeriving #-} data A deriving instance Read A }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130515 for x86_64-unknown-linux): Prelude.foldr1: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Oddly, the "panic" message is given only by ghc, not ghci, but this is minor.) While the Read instance seems to be of little use, it can be used for reading types such as `Either Void Int`. Patch attached. </pre> GHC 2013-05-24T17:05:25 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43451 <pre>#7930: Nested STM Invariants are lost ----------------------------------------+----------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: STM Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Invariants from a successful nested transaction should be merged with the parent. {{{ import Control.Concurrent import Control.Concurrent.STM main = do x &lt;- atomically $ do a &lt;- newTVar True (always (readTVar a) &gt;&gt; retry) `orElse` return () return a atomically (writeTVar x False) -- Should not and does not fail y &lt;- atomically $ do a &lt;- newTVar True always (readTVar a) `orElse` return () return a atomically (writeTVar y False) -- Should fail, but does not! putStrLn "Ahhh!" z &lt;- atomically $ do a &lt;- newTVar True always (readTVar a) return a atomically (writeTVar z False) -- should and does fail }}} I know how to fix this. I'll have a patch with some tests and a fix soon. </pre> GHC 2013-05-24T16:26:24 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43442 <pre>#7929: -pgma and -pgmc flags dont work as expected on mac -------------------------+-------------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: 7678 Blocking: | Related: 7922,7678 -------------------------+-------------------------------------------------- This is a bug report version of a related ticket. As I discuss in [http://hackage.haskell.org/trac/ghc/ticket/7922#comment:23 this ticket], the Assembler available on the Mac OS X platform does not support AVX instructions, though the operating system/ platform does. Clang, because it uses LLVM as a backend, supports AVX, and can generate AVX simd ops in the object code directly, or AVX assembly, or assemble assembly that uses AVX. Clang will select AVX instructions on SandyBridge or newer macs when given the -march=native flag. There is another subtlety: the Apple Developer tools version of gcc 4.2 is old enough that it doesn't understand -march=native / doesn't support avx, and while newer versions of gcc (eg gcc 4.8), understand -march=native, and can choose -march=corei7-avx as appropriate (which corresponds to most new macs of the past 2 years), and while these newer gcc's can generate assembly that uses AVX instructions, these newer gcc's still seem to try to use the system assembler. Now, one would think/hope that passing {{{ -pgma clang -pgmc clang }}} to ghc would resolve this build problem, however, this does not seem to work, though as documented in the related ticket, calling clang directly with the flags that ghc would generate DOES work correctly, (but calling clang by hand is no substitute for a compilation driver) {{{ clang -march=native -mavx $flags -S foo.c clang -march=native -mavx $flags -c foo.s }}} what *does* work is change the settings file that gets installed with ghc (for me this file is at /user/local/lib/ghc-7.6.2/settings) to have '''clang''' as the default ghc compiler rather than '''gcc'''. This makes the build work on the toy test case, but because of the [http://hackage.haskell.org/trac/ghc/ticket/7678 clang cpp problem ticket], clang is not a viable default compiler setting for ghc as yet. The fact that changing the settings file compiler from gcc -&gt; clang worked, but doing {{{-pgma clang -pgmc clang }}} does not, suggest either those flags are incorrectly implemented for OS X ghcs, or there is some switch that isn't toggled by the currently exposed compiler passes. I can work around these corner cases, at the cost of some complexity in my build tooling, but the fact that the -pgma clang -pgmc clang bits didn't work, but changing the settings file did work (something that really isn't a good idea given how clang and ghc interact wrt c pre processor), suggests that some part of the build process for the c -&gt; object code path in the ghc driver isn't being configured properly by the standard program flags, but is changed by the settings file. So this suggests that semantically there is some bug in the driver, or a part of the build process that doesn't have a flag exposed yet, but which behaves different subject to change the compiler choice in the ghc settings file. This seems like a misfeature. </pre> GHC 2013-05-24T04:34:03 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43439 <pre>#7928: GHC fails to terminate while compiling with optimizations -----------------------------+---------------------------------------------- Reporter: Ptharien's Flame | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When I try to compile random-fu-0.2.4.0 from Hackage, using the command: {{{ cabal install --ghc --ghc-options="-fllvm -O2 -dcore-lint" --enable- optimization=2 random-fu-0.2.4.0 }}} I get the following output: {{{ Resolving dependencies... Configuring random-fu-0.2.4.0... Building random-fu-0.2.4.0... Preprocessing library random-fu-0.2.4.0... [ 1 of 27] Compiling Data.Random.Internal.Find ( src/Data/Random/Internal/Find.hs, dist/build/Data/Random/Internal/Find.o ) [ 2 of 27] Compiling Data.Random.Internal.Fixed ( src/Data/Random/Internal/Fixed.hs, dist/build/Data/Random/Internal/Fixed.o ) [ 3 of 27] Compiling Data.Random.Internal.TH ( src/Data/Random/Internal/TH.hs, dist/build/Data/Random/Internal/TH.o ) [ 4 of 27] Compiling Data.Random.Lift ( src/Data/Random/Lift.hs, dist/build/Data/Random/Lift.o ) [ 5 of 27] Compiling Data.Random.RVar ( src/Data/Random/RVar.hs, dist/build/Data/Random/RVar.o ) [ 6 of 27] Compiling Data.Random.Distribution ( src/Data/Random/Distribution.hs, dist/build/Data/Random/Distribution.o ) [ 7 of 27] Compiling Data.Random.Distribution.Uniform ( src/Data/Random/Distribution/Uniform.hs, dist/build/Data/Random/Distribution/Uniform.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package MonadPrompt-1.0.0.3 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.4.0 ... linking ... done. Loading package th-extras-0.0.0.2 ... linking ... done. Loading package flexible-defaults-0.0.1.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package mersenne-random-pure64-0.2.0.3 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package mwc-random-0.12.0.1 ... linking ... done. Loading package stm-2.4.2 ... linking ... done. Loading package stateref-0.3 ... linking ... done. Loading package random-source-0.3.0.4 ... linking ... done. Loading package rvar-0.2.0.1 ... linking ... done. Loading package MonadRandom-0.1.9 ... linking ... done. Loading package random-shuffle-0.0.4 ... linking ... done. Loading package monad-loops-0.4.2 ... linking ... done. Loading package continued-fractions-0.9.1.1 ... linking ... done. Loading package converge-0.1.0.1 ... linking ... done. Loading package gamma-0.9.0.2 ... linking ... done. Loading package erf-2.0.0.0 ... linking ... done. [ 8 of 27] Compiling Data.Random.List ( src/Data/Random/List.hs, dist/build/Data/Random/List.o ) [ 9 of 27] Compiling Data.Random.Distribution.Bernoulli ( src/Data/Random/Distribution/Bernoulli.hs, dist/build/Data/Random/Distribution/Bernoulli.o ) [10 of 27] Compiling Data.Random.Distribution.Categorical ( src/Data/Random/Distribution/Categorical.hs, dist/build/Data/Random/Distribution/Categorical.o ) *** Core Lint warnings : in result of Desugar (after optimization) *** &lt;no location info&gt;: Warning: [RHS of $c&gt;&gt;_aMYc :: forall p_aMMn. GHC.Num.Num p_aMMn =&gt; forall a_a3Jr b_a3Js. Data.Random.Distribution.Categorical.Categorical p_aMMn a_a3Jr -&gt; Data.Random.Distribution.Categorical.Categorical p_aMMn b_a3Js -&gt; Data.Random.Distribution.Categorical.Categorical p_aMMn b_a3Js] INLINE binder is (non-rule) loop breaker: $c&gt;&gt;_aMYc }}} It then freezes for an as-far-as-I-known indefinite amount of time; I have tried it several times, and it never moves beyond that. Once, I left it for two whole hours without any change. Every time, I have had to manually interrupt it with {{{ctrl-c}}}. On the other hand, if I instead use the command: {{{ cabal install --ghc --ghc-options="-fllvm -O1 -dcore-lint" --enable- optimization=1 random-fu-0.2.4.0 }}} It produces literally identitical output up to the point that the first command stopped at, but it continues as normal afterwards and finishes installing random-fu as expected. My terminal confirms that the {{{ghc}}} executable (as opposed to, say, {{{opt}}} or {{{llc}}}) is the one that the first command gets stuck on. </pre> GHC 2013-05-24T01:00:45 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43437 <pre>#7927: Error in 'lift' line causes the 'impossible' to happen -------------------------------+-------------------------------------------- Reporter: MitchellSalad | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- import Control.Monad.Trans.Class (lift) import Control.Monad.Trans.Maybe (MaybeT) foo :: MaybeT IO () foo = lift putStrLn "foo" -------- This code caused the following output from GHC: Couldn't match kind `* -&gt; *' with `*' Expected type: [Char] -&gt; MaybeT IO () Actual type: [Char] -&gt; MaybeT IO () Kind incompatibility when matching types: [Char] :: * -&gt; * [Char] :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult &lt;&lt;details unavailable&gt;&gt; -------- The line should of course be 'lift $ putStrLn "foo"'. Apologies if this is a duplicate bug. </pre> GHC 2013-05-23T23:13:12 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43421 <pre>#7926: eventfd: unsupported operation when doing anything --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I'm using Debian jessie; sources.list is thus: {{{deb http://ftp.us.debian.org/debian jessie main contrib non-free}}} Ran apt-get upgrade 10 minutes ago. The contents of /var/log/apt/history.log (sorry for the massive list, not sure how to narrow it down): https://gist.github.com/joelteon/07c912a3e7e49be820cc ghc/ghci output (exit 1): {{{eventfd: unsupported operation (Function not implemented)}}} When launching a precompiled executable, the first time it executes an I/O action (exit 1): {{{hClose: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:84:3-10}}} `strace ghci` output is in this gist: https://gist.github.com/anonymous/dcc02c8b29a65ec49be6 </pre> GHC 2013-05-22T22:42:39 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43420 <pre>#7925: ghc 7.4.2 builds with errors on Red Had Enterprise Linux 6 -------------------+-------------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -------------------+-------------------------------------------------------- GHC 7.4.2 builds on RHEL 6, but with three test failures. None of these errors are show-stopping, and we seem to have a good Haskell Platform now built on top, but since 7.4.2 is a numbered release, the failures were unexpected, so I am reporting them. {{{ &gt; &gt; Unexpected failures: &gt; &gt; lib/Time T5430 [bad stdout] (normal) &gt; &gt; perf/compiler parsing001 [stat not good enough] (normal) &gt; &gt; simplCore/should_compile spec-inline [stderr mismatch] (optasm) }}} </pre> GHC 2013-05-22T21:10:39 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43414 <pre>#7924: throwIO gets subsumed by a later imprecise exception -----------------------------+---------------------------------------------- Reporter: dmwit | 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: -----------------------------+---------------------------------------------- The code below exits with exception "Boom" when compiled with no options (the expected behavior, since throwIO should always subsume exceptions that come later in the IO monad), but with a head-of-empty-list exception when compiled with -O. Similar code has shown this problem on 7.2 and 7.4. {{{ {-# LANGUAGE DeriveDataTypeable #-} import Control.Exception (throwIO, Exception) import Control.Monad (when) import Data.Typeable (Typeable) data Boom = Boom deriving (Show, Typeable) instance Exception Boom main = do args &lt;- return [] -- Should throw this exception. when (length args /= 1) (throwIO Boom) -- With -O, instead throws this one from head []. let n = read (head args) when (n &lt; 0) (throwIO Boom) return (fromInteger n :: Int) }}} </pre> GHC 2013-05-22T13:40:45 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43375 <pre>#7923: Optimization for takeMVar/putMVar when MVar left empty ------------------------------------+--------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Right now, we always add an MVar to the mutable list when we takeMVar/putMVar. However, this is unnecessary when the MVar is left empty. This patch arranges that we don't add the MVar to the mutable list in those cases. I've validated the patch but haven't checked performance changes yet. </pre> GHC 2013-05-20T22:46:23 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43374 <pre>#7922: adding direct *.c -&gt; object code (*.o/so/dylib) support to compilation driver -----------------------------+---------------------------------------------- Reporter: carter | 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: #7904 -----------------------------+---------------------------------------------- currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats. Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like {{{ gcc source.c -c }}} rather than {{{ gcc source.c -s -c }}} (these are not necessarily the right flags, but rather a strawman representation of the difference). on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef Likewise, when doing -fllvm compilation, the *.c-&gt; *.s phase just slows down the compilation process period. I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes This is not </pre> GHC 2013-05-20T21:29:33 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43372 <pre>#7921: DSO linking bug in unix package -------------------------------+-------------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {{{unix}}} depends on {{{libpthread}}}, but it's not listed under {{{extra-libraries}}} in the cabal file. For that reason some programs fail to build on Ubuntu 13.04. Steps to reproduce: {{{ -- Main.hs import System.Posix.Semaphore main :: IO () main = do semUnlink "foo" }}} {{{ $ ghc --make Main.hs }}} Expected result: Program is compiled and linked. Actual result: Liking fails with {{{ /usr/bin/ld: /home/foo/.install/haskell/ghc-7.6.2/lib/ghc-7.6.2/unix-2.6.0.1/libHSunix-2.6.0.1.a(Semaphore__5.o): undefined reference to symbol 'sem_unlink&lt; at &gt;&lt; at &gt;GLIBC_2.2.5' /usr/bin/ld: note: 'sem_unlink&lt; at &gt;&lt; at &gt;GLIBC_2.2.5' is defined in DSO /lib/x86_64 -linux-gnu/libpthread.so.0 so try adding it to the linker command line /lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status }}} This is related to https://fedoraproject.org/wiki/UnderstandingDSOLinkChange. </pre> GHC 2013-05-20T13:12:03 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43359 <pre>#7920: type-checker panic (kindFunResult) -------------------------------+-------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {{{ *Main&gt; :t (() :: m () -&gt; t m) () () &lt;interactive&gt;:1:1: Couldn't match kind `* -&gt; *' with `OpenKind' Expected type: () -&gt; t0 Actual type: () -&gt; t0 Kind incompatibility when matching types: t_n :: * -&gt; * t0 :: OpenKind The function `() ::ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): kindFunResult &lt;&lt;details unavailable&gt;&gt; Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} </pre> GHC 2013-05-18T22:30:11 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43350 <pre>#7919: Heap corruption (segfault) from large 'let' expression --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts. {{{ LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208 (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.) It looks like a pretty clear case of heap corruption. I'll explain why... The test program uses TH to generate a program that looks like this: {{{ data Large = Large Int Int ... -- 512 non-strict Int fields test = let step (Large i1 i2 ... i512) = let j1 = i1 + i4 j2 = i2 + i7 ... j511 = i511 + i510 j512 = i512 + i1 in Large j1 j2 ... j512 in runSteps step 100000 (Large 1 1 ... 1) -- basically an unfoldr: runSteps :: (state -&gt; (state, Int)) -&gt; Int -&gt; state -&gt; [Int] runSteps f n i | n &lt;= 0 = [] | otherwise = case f i of (i', r) -&gt; r : runSteps f (n - 1) i' }}} We use TH to generate this program, and we use a "size" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails. For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks... {{{ // If this block does not have enough space to allocate the // current object, but it also doesn't have any work to push, then // push it on to the scanned list. It cannot be empty, because // then there would be enough room to copy the current object. if (bd-&gt;u.scan == bd-&gt;free) { ASSERT(bd-&gt;free != bd-&gt;start); push_scanned_block(bd, ws); } }}} So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures. But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec. Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's. {{{ case tpl_s6jQ of tpl_s6Ak { __DEFAULT -&gt; case tpl_s6jS of tpl_s6Al { __DEFAULT -&gt; case tpl_s6jU of tpl_s6Am { -- etc for all 500+ elements }}} versus {{{ let { sat_s5UK :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in let { sat_s62X :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in let { sat_s62W :: GHC.Types.Int [LclId] = \u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in -- etc for all 500+ elements }}} Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails. </pre> GHC 2013-05-17T20:31:16 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43348 <pre>#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------+---------------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Quote qq = QuasiQuoter { quoteExp = \str -&gt; case str of "a" -&gt; [| True |] "b" -&gt; [| id True |] "c" -&gt; [| True || False |] "d" -&gt; [| False |] , quotePat = undefined , quoteType = undefined , quoteDec = undefined } {-# LANGUAGE QuasiQuotes #-} module B where import A ex1 = [qq|a|] ex2 = [qq|b|] ex3 = [qq|c|] ex4 = [qq|d|] }}} In the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi- quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the "contents" of the quasi-quote. </pre> GHC 2013-05-17T14:24:38 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43347 <pre>#7917: update documentation of InstalledPackageInfo -----------------------------+---------------------------------------------- Reporter: Lemming | Owner: Type: task | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When writing a binding to a foreign package that does not support pkg- config, it seems to be essential to know what the fields of InstalledPackageInfo precisely mean. I find the current description in section 4.9.8 of the GHC doc too short. What does extra-ghci-libraries mean? It is undocumented. In which field I should list shared objects? In which field I should enumerate static link libraries? Which libraries are used when compiling with -dynamic option and which ones are used for static linking? Are the library paths used both for static and dynamic link libraries? Which fields affect compilation of included C files? Which fields affect GHCi and which ones affect GHC? </pre> GHC 2013-05-17T12:07:36 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43343 <pre>#7916: PolyKinds without type signatures --------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE PolyKinds, ExplicitForAll #-} f :: forall (m :: k -&gt; *) (a :: k). m a -&gt; m a f = id g = f }}} I would expect GHC to infer the same type for `g` as for `f`. However, it gives the AnyK kind, and `g` is not possible to use: {{{ ghci -Wall X.hs ... X.hs:5:1: Warning: Top-level binding with no type signature: g :: forall (m :: AnyK -&gt; *) (a :: AnyK). m a -&gt; m a Ok, modules loaded: Main. *Main&gt; g "a" &lt;interactive&gt;:2:1: Kind incompatibility when matching types: a0 :: AnyK Char :: * In the first argument of ‛print’, namely ‛it’ In a stmt of an interactive GHCi command: print it }}} </pre> GHC 2013-05-16T17:30:36 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43339 <pre>#7915: Documentation uses deprecated record GADT syntax ------------------------------+--------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Trivial patch attached. </pre> GHC 2013-05-16T13:52:32 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.bugs/43331 <pre>#7914: base library's MD5 symbols clash with others -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- We have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but different ABIs. Depending on the order in which the linker runs across the object files, we end up with a crash during application startup as a result of one component picking up the other component's MD5 symbols. The offending source file is libraries/base/cbits/md5.c. A simple fix for this would be to prefix the function names with e.g. _ghc_ or something similar, so that the names would not clash. There are perhaps other functions in base (probably many others) that could benefit from a similar treatment, but we're not crashing on those yet. </pre> GHC 2013-05-16T03:22:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.bugs