Re: Occasional segfault in GHCi w/ 7.4.1-rc1 and 64bit OS X

2011-12-24 Thread Brandon Allbery 
On Sun, Dec 25, 2011 at 00:35, austin seipp  wrote:

> I looked at the shell scripts that invoke GHC and ran GDB with the
> proper arguments. I got a backtrace like so:
>

I would not place much faith in this particular backtrace; gdb is badly
broken on SL and Lion, it gets seriously mucked up by the way shared
library stubs work (probably among other issues, but this one was easy to
spot:  just try to trace through such a call), and I get failures running
stuff in gdb that do not happen outside of it.  Backtraces from core files
are okay, but running something inside gdb will often fail in quasi-random
places.

(there's a bug open in MacPorts about it.  someone did manage to get the
very latest gdb to work at one point, but both Apple's and MacPorts' gdbs
are known to fail.)

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Occasional segfault in GHCi w/ 7.4.1-rc1 and 64bit OS X

2011-12-24 Thread Antoine Latter 
On Sun, Dec 25, 2011 at 12:35 AM, austin seipp  wrote:
> 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.
>

A data point:

I've been testing out the RC, including minimal use of ghci, on a
similar machine (same OS and arch).

I've been using a 32-bit source build of RC and I haven't seen
anything like this.

Antoine

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Occasional segfault in GHCi w/ 7.4.1-rc1 and 64bit OS X

2011-12-24 Thread austin seipp 
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: 0xae21cf68
0x0001ae2060da in evacuate1 ()
(gdb) bt
#0  0x0001ae2060da in evacuate1 ()
#1  0x0001ae20b868 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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Unit unboxed tuples

2011-12-24 Thread David Menendez 
On Sat, Dec 24, 2011 at 7:15 AM, Duncan Coutts
 wrote:
> On 23 December 2011 20:09, Stefan Holdermans  wrote:
>>> Here are the kinds of the type constructors:
>>>
>>>                 (,,) :: * -> * -> * -> *
>>>                 (,) :: * -> * -> *
>>>                 () :: *
>>>
>>>                 (# ,, #) :: * -> * -> * -> #
>>>                 (# , #) :: *  -> * -> #
>>> BUT
>>>                 (#  #) :: * -> #
>>
>> Just of out curiosity, what would be a compelling use case for singleton and 
>> unit unboxed tuples?
>
> For singleton unboxed tuples, any situation where you want to return a
> single value but not force its evaluation. This occurs for example
> with some low level functions in the implementation of ordinary lazy
> arrays.

How is that different from returning a normal value?

-- 
Dave Menendez 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Unit unboxed tuples

2011-12-24 Thread Duncan Coutts 
On 23 December 2011 20:09, Stefan Holdermans  wrote:
>> Here are the kinds of the type constructors:
>>
>>                 (,,) :: * -> * -> * -> *
>>                 (,) :: * -> * -> *
>>                 () :: *
>>
>>                 (# ,, #) :: * -> * -> * -> #
>>                 (# , #) :: *  -> * -> #
>> BUT
>>                 (#  #) :: * -> #
>
> Just of out curiosity, what would be a compelling use case for singleton and 
> unit unboxed tuples?

For singleton unboxed tuples, any situation where you want to return a
single value but not force its evaluation. This occurs for example
with some low level functions in the implementation of ordinary lazy
arrays.

Duncan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1

2011-12-24 Thread Joachim Breitner 
Hi,

Am Samstag, den 24.12.2011, 08:28 +1100 schrieb Erik de Castro Lopo:
> Joachim Breitner wrote:
> 
> > ghc-stage2: panic! (the 'impossible' happened)
> >   (GHC version 7.4.0.20111219 for powerpc-unknown-linux):
> > Cant do annotations without GHCi
> > {libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33}
> > base:GHC.Exts.ForceSpecConstr{d rbL}
> 
> Thats related to the problem of GHCi being broken on powerpc.

Somewhat: vector uses annotations, annotation need GHCi, GHCi is
disabled (because broken) on powerpc, vector is bundled by accident in
GHC (and will be removed in the final release, unless I am mistaken),
and the real vector package is patched in Debian to handle this
(http://patch-tracker.debian.org/patch/series/view/haskell-vector/0.9-2/no_ann_without_ghci).
 My hope is that ghc will in the future ignore annotations on non-GHCi-arches 
(http://hackage.haskell.org/trac/ghc/ticket/4268).

Once vector is unbundled, I expect the build to succeed on powerpc. I
guess the other weird-arch builds would have failed at this point as
well, if they had not failed due to the various other reasons earlier; I
hope these get fixed in the final release.

Maybe Debian should offer GHC to run buildbots
(http://hackage.haskell.org/trac/ghc/wiki/Builder) on at least some of
our weird arch machines, so that these problems will be noticed.
earlier. But I’m not sure if the DSA team allows such a thing, as we’d
be running code that is not under our control. Is someone in the Haskell
team interested in finding that out?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users