- Glasgow-haskell-users

Occasional segfault in GHCi w/ 7.4.1-rc1 and 64bit OS X
by austin seipp 17 Jul '12

17 Jul '12

Hello GHC hackers, I have been trying the recent 7.4.1-rc1 release on my OSX Snow Leopard machine. I am using the 64bit OSX .tar.bz. I used virthualenv/hsenv to set up a virtual environment to test packages with the RC, but I discovered that GHCi seems to segfault somewhat randomly when invoked. I cannot reproduce this problem with 7.0.4 (64bit,) 7.2.2 (64bit,) or 7.5.20111223 (also 64bit.) I have invoked GHCi probably a hundred times each, and have never had it crash. I can crash the RC fairly reliably however. I looked at the shell scripts that invoke GHC and ran GDB with the proper arguments. I got a backtrace like so: $ gdb /Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219/ghc GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(ffi64.o)" - no debug information available for "../src/x86/ffi64.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(prep_cif.o)" - no debug information available for "../src/prep_cif.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(types.o)" - no debug information available for "../src/types.c". (gdb) r -B/Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219 --interactive Starting program: /Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219/ghc -B/Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219 --interactive Reading symbols for shared libraries + done GHCi, version 7.4.0.20111219: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000ae21cf68 0x00000001ae2060da in evacuate1 () (gdb) bt #0 0x00000001ae2060da in evacuate1 () #1 0x00000001ae20b868 in scavenge_block1 () Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) So it looks like a GC bug at first glance, but I haven't done rigorous investigation. Again this doesn't happen every time - probably 1/3 the time it crashes, the other 2/3 the time it seems to work fine. This naturally also affects `runghc`. Is this a known issue? Or should I file a bug and investigate further? Perhaps something forgot to get something merged into the 7.4 branch? -- Regards, Austin

7 8

Call to arms: lambda-case is stuck and needs your help
by Mikhail Vorozhtsov 17 Jul '12

17 Jul '12

Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359

27 72

"containing" memory-consuming computations
by Herbert Valerio Riedel 16 Jul '12

16 Jul '12

Hello GHC Devs, One issue that's been bothering me when writing Haskell programs meant to be long-running processes performing computations on external input-data in terms of an event/request-loop (think web-services, SQL-servers, or REPLs), that it is desirable to be able to limit resource-usage and be able to "contain" the effects of computations which exhausts the resource-limits (i.e. w/o crashing and burning the whole process) For the time-dimension, I'm already using functions such as System.Timeout.timeout which I can use to make sure that even a (forced) pure computation doesn't require (significantly) more wall-clock time than I expect it to. But I'm missing a similar facility for constraining the space-dimension. In some other languages such as C, I have (more or less) the ability to check for /local/ out-of-memory conditions (e.g. by checking the return value of e.g. malloc(3) for heap-allocations, or by handling an OOM exception), rollback the computation, and be able to skip to the next computation request (which hopefully requires less memory...) So, is there already any such facility provided by the GHC Platform I've missed so far? ...and if not, would such a memory-limiting facility be reconcilable with the GHC RTS architecture? Cheers, hvr --

6 8

“Ambiguous type variable in the constraint” error in rewrite rule
by Tsuyoshi Ito 16 Jul '12

16 Jul '12

Hello, Why does GHC 7.4.1 reject the rewrite rule in the following code? > module Test where > > import Data.Monoid > import Control.Monad.Writer.Strict > > f :: Monad m => a -> m a > f = return > > g :: Monoid w => a -> Writer w a > g = return > > {-# RULES > "f->g" f = g > #-} On the line containing the rewrite rule, GHC shows the following error message: Test.hs:13:12: Ambiguous type variable `w0' in the constraint: (Monoid w0) arising from a use of `g' Probable fix: add a type signature that fixes these type variable(s) In the expression: g When checking the transformation rule "f->g" Interestingly, the code compiles if the rewrite rule is replaced with the following SPECIALIZE pragma: > {-# SPECIALIZE f :: Monoid w => a -> Writer w a #-} I find this strange because if I am not mistaken, this specialization is handled by using a rewrite rule of the same type as the one which GHC rejects. The following ticket might be related, but I am not sure: Subclass Specialization in Rewrite Rules http://hackage.haskell.org/trac/ghc/ticket/6102 Best regards, Tsuyoshi

2 3

Type error when deriving Generic for an associated data type
by Bas van Dijk 13 Jul '12

13 Jul '12

Hi, I'm hitting on an issue when deriving Generic for an associated data type: {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics class Foo a where data T a :: * instance Foo Int where data T Int = Bla deriving Generic Couldn't match type `Rep (T Int)' with `M1 t0 t1 (M1 t2 t3 U1)' Expected type: Rep (T Int) x Actual type: M1 t0 t1 (M1 t2 t3 U1) x In the pattern: M1 (M1 U1) In an equation for `to': to (M1 (M1 U1)) = Bla In the instance declaration for `Generic (T Int)' The GHC trac seems to be down. Is this a known issue? Cheers, Bas

3 3

How to describe this bug?
by Sönke Hahn 13 Jul '12

13 Jul '12

Hi! I've discovered a strange bug that violates simple equational reasoning. Basically, something similar to this: let a = f x in a == f x evaluates to False. I'd like to report this on ghc-trac, but I realised, that I don't know a good name for behaviour like this. Is there one? "Broken referential transparency", perhaps? Thanks, Sönke

10 20

GHC ARM builds?
by Austin Seipp 13 Jul '12

13 Jul '12

With 7.4.2, the patches for full ARM linker support were merged and released. Are there any official builds of GHC for Linux/ARM yet? I have a PandaBoard ES I'd be willing to contribute for builds and/or testing/development, but I don't know where to get a GHC for bootstrapping. It's also worth asking if there's any page documenting needed prerequisites/expected build environment. If not it should be added to the wiki (I don't see any as of right now.) -- Regards, Austin

4 5

Imported foreign functions should be strict
by Favonia 12 Jul '12

12 Jul '12

Hi all, Recently I am tuning one of our incomplete libraries that uses FFI. After dumping the interface file I realized strictness/demand analysis failed for imported foreign functions---that is, they are not inferred to be strict in their arguments. In my naive understanding all imported foreign functions are strict! Here's a minimum example (with GHC 7.4.2): {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign.C foreign import ccall unsafe "sin" sin' :: CDouble -> CDouble where in the interface file the function sin' will have strictness U(L) (meaning Unpackable(Lazy)). Regards, Favonia

3 3

[Fwd: Memory corruption issues when using newAlignedPinnedByteArray, GC kicking in?]
by Nicolas Trangez 11 Jul '12

11 Jul '12

All, I sent this mail to Haskell Cafe earlier today, and was pointed [1] at this list. As such... Any help/advice would be greatly appreciated! Thanks, Nicolas [1] http://www.haskell.org/pipermail/haskell-cafe/2012-July/102242.html -------- Forwarded Message -------- > From: Nicolas Trangez <nicolas(a)incubaid.com> > To: haskell-cafe(a)haskell.org > Cc: Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > Subject: Memory corruption issues when using > newAlignedPinnedByteArray, GC kicking in? > Date: Tue, 10 Jul 2012 19:20:01 +0200 > > All, > > While working on my vector-simd library, I noticed somehow memory I'm > using gets corrupted/overwritten. I reworked this into a test case, and > would love to get some help on how to fix this. > > Previously I used some custom FFI calls to C to allocate aligned memory, > which yields correct results, but this has a significant (+- 10x) > performance impact on my benchmarks. Later on I discovered the > newAlignedPinnedByteArray# function, and wrote some code using this. > > Here's what I did in the test case: I created an MVector instance, with > the exact same implementation as vector's > Data.Vector.Storable.Mutable.MVector instance, except for basicUnsafeNew > where I pass one more argument to mallocVector [1]. > > I also use 3 different versions of mallocVector (depending on > compile-time flags): > > mallocVectorOrig [2]: This is the upstream version, discarding the > integer argument I added. > > Then here's my first attempt, very similar to the implementation of > mallocPlainForeignPtrBytes [3] at [4] using GHC.* libraries. > > Finally there's something similar at [5] which uses the 'primitive' > library. > > The test case creates vectors of increasing size, then checks whether > they contain the expected values. For the default implementation this > works correctly. For both others it fails at some random size, and the > values stored in the vector are not exactly what they should be. > > I don't understand what's going on here. I suspect I lack a reference > (or something along those lines) so GC kicks in, or maybe the buffer > gets relocated, whilst it shouldn't. > > Basically I'd need something like > > GHC.ForeignPtr.mallocPlainAlignedForeignPtrBytes :: Int -> Int -> IO > (ForeignPtr a) > > Thanks, > > Nicolas > > [1] https://gist.github.com/3084806#LC37 > [2] https://gist.github.com/3084806#LC119 > [3] > http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Fo… > [4] https://gist.github.com/3084806#LC100 > [5] https://gist.github.com/3084806#LC81 > >

2 2

Re: How to describe this bug?
by Tyson Whitehead 10 Jul '12

10 Jul '12

On July 10, 2012 10:39:41 Colin Adams wrote: > Sure they would be better modelled that way, but the whole point of using > floating point arithmetic is to sacrifice accuracy for performance, is it > not? True. I just find it interesting that some types have a builtin Nothing value. Some further examples are pointer (where NULL is Nothing) and clamped/saturation arithmetic (where min and max values are Nothing). It would be nice if somehow they could be unified at the top level without the performance penalty associated with a genuine Maybe value. Another possibility might be to consider NaN to encode bottom in Float#. When you constructed Float from Float# with a NaN it would give bottom. Would the existance of unboxed lifted types be a problem? Cheers! -Tyson

1 0