ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
Hi!

Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
version (6.8.3) and then, in a second try I used the self build 6.10.1 to
build it again.

I added building of api docs with:
$ echo "HADDOCK_DOCS = YES" >> mk/build.mk

I configured it with a simple ./configure and not more options.

The compiler seems to work well on both versions.


But if i try to start ghci I get the following:

---- snip ----
$ ghci

GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
ghc: Unable to mmap() for jump islands

Loading package ghc-prim ... ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.1 for x86_64-unknown-freebsd):
          loadObj: failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

---- snip ----

It looks he has some kind of library loading problems?

Any ideas?

Thnx and regards
Markus


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

attachment0 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Brandon S Allbery KF8NH
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
> Because the ports seem not to get updated, I tried to compile ghc  
> 6.10.1
> under freebsd 7 on amd64 myself. For compiling I first used the  
> ports ghc

The tree's not being updated because 64-bit on freebsd doesn't work  
yet, as you found.  I believe a fix for the mmap() problem has been  
committed for the upcoming 6.10.2.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Brandon S. Allbery KF8NH wrote:
> On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
>> Because the ports seem not to get updated, I tried to compile ghc 6.10.1
>> under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
>
> The tree's not being updated because 64-bit on freebsd doesn't work yet,
> as you found.  I believe a fix for the mmap() problem has been committed
> for the upcoming 6.10.2.

Yes.

http://hackage.haskell.org/trac/ghc/ticket/2063

The patches haven't been merged into stable yet, but you can grab a HEAD
snapshot and try that instead - we'd appreciate the testing.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
On Thu 27.11 09:49, Simon Marlow wrote:

> Brandon S. Allbery KF8NH wrote:
> >On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
> >>Because the ports seem not to get updated, I tried to compile ghc 6.10.1
> >>under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
> >
> >The tree's not being updated because 64-bit on freebsd doesn't work yet,
> >as you found.  I believe a fix for the mmap() problem has been committed
> >for the upcoming 6.10.2.
>
> Yes.
>
> http://hackage.haskell.org/trac/ghc/ticket/2063
>
> The patches haven't been merged into stable yet, but you can grab a HEAD
> snapshot and try that instead - we'd appreciate the testing.
I checked out and translated the head version of ghc today from darcs.
It compiled fine. When I now try to start the ghci I get the following:

---- snip ----
GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 626688 bytes at 0x40000000, got 0x801635000.  Try specifying an address with +RTS -xm<addr> -RTS
    (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
            Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
                Abort (core dumped)
---- snip ----

If it helps somehow, you can find the core dump here:
http://www.alios.org/~alios/ghc.core.bz2

Regards
Markus


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

attachment0 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Markus Barenhoff wrote:

> On Thu 27.11 09:49, Simon Marlow wrote:
>> Brandon S. Allbery KF8NH wrote:
>>> On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
>>>> Because the ports seem not to get updated, I tried to compile ghc 6.10.1
>>>> under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
>>> The tree's not being updated because 64-bit on freebsd doesn't work yet,
>>> as you found.  I believe a fix for the mmap() problem has been committed
>>> for the upcoming 6.10.2.
>> Yes.
>>
>> http://hackage.haskell.org/trac/ghc/ticket/2063
>>
>> The patches haven't been merged into stable yet, but you can grab a HEAD
>> snapshot and try that instead - we'd appreciate the testing.
>
> I checked out and translated the head version of ghc today from darcs.
> It compiled fine. When I now try to start the ghci I get the following:
>
> ---- snip ----
> GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
> ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 626688 bytes at 0x40000000, got 0x801635000.  Try specifying an address with +RTS -xm<addr> -RTS
>     (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
>    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> Abort (core dumped)
> ---- snip ----
>
> If it helps somehow, you can find the core dump here:
> http://www.alios.org/~alios/ghc.core.bz2

That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working
fine (or is it?).

Ideally I need to find out what the memory map is for GHCi.  I posted some
instructions for doing this on Linux/Xen, maybe you can adapt these to work
on FreeBSD:

http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/016091.html

The bit that needs to change is 'cat /proc/<pid>/maps' - does FreeBSD have
something similar?

Also you could try doing as the error message suggests, and specify a
different address.  e.g.

   ghci +RTS -xm30000000
   ghci +RTS -xm50000000

for 0.75 and 1.25GB respectively.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
On Fri 28.11 09:42, Simon Marlow wrote:
> Markus Barenhoff wrote:
> >On Thu 27.11 09:49, Simon Marlow wrote:


Hi!

> >I checked out and translated the head version of ghc today from darcs.
> >It compiled fine. When I now try to start the ghci I get the following:
> >
> >---- snip ----
> >GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
> >ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for
> >626688 bytes at 0x40000000, got 0x801635000.  Try specifying an address
> >with +RTS -xm<addr> -RTS
> >    (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
> >    Please report this as a GHC bug:  
> >    http://www.haskell.org/ghc/reportabug
> > Abort (core dumped)
> >---- snip ----
> >
> >If it helps somehow, you can find the core dump here:
> >http://www.alios.org/~alios/ghc.core.bz2
>
> That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working
> fine (or is it?).
yes, it worked, but I haven't installed anymore - so I'am not sure, where it
does maps its stuff into memory.

>
> Ideally I need to find out what the memory map is for GHCi.  I posted some
> instructions for doing this on Linux/Xen, maybe you can adapt these to work
> on FreeBSD:
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2008-November/016091.html
>
> The bit that needs to change is 'cat /proc/<pid>/maps' - does FreeBSD have
> something similar?
>
I tried it with the following results:

---- gdb session ----
(gdb) run --interactive -B/usr/local/lib/ghc-6.11.20081126/.
Starting program: /usr/local/lib/ghc-6.11.20081126/ghc --interactive -B/usr/local/lib/ghc-6.11.20081126/.
(no debugging symbols found)...[New LWP 100250]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x801e01120 (LWP 100250)]
[New Thread 0x801e01290 (LWP 100334)]
[New Thread 0x801e01400 (LWP 100335)]
GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 626688 bytes at 0x40000000, got 0x801635000.  Try specifying an address with +RTS -xm<addr> -RTS
    (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x801e01120 (LWP 100250)]
0x0000000801bcb1dc in thr_kill () from /lib/libc.so.7
---- gdb session ----

---- process virtual memeory ----
# cat /proc/65557/map
0x400000 0x1507000 3126 3539 0xffffff0026bfe270 r-x 2 1 0x4 COW NC vnode /usr/local/lib/ghc-6.11.20081126/ghc
0x1607000 0x179e000 404 0 0xffffff00032e3a90 rw- 1 0 0x2104 COW NNC vnode /usr/local/lib/ghc-6.11.20081126/ghc
0x179e000 0x17a2000 4 0 0xffffff001c260b60 rw- 1 0 0x2104 NCOW NNC default -
0x801607000 0x80162c000 27 0 0xffffff001b143000 r-x 1 0 0x2104 COW NNC vnode /libexec/ld-elf.so.1
0x80162c000 0x801635000 8 0 0xffffff003789d820 rw- 1 0 0x2104 NCOW NNC default -
0x801635000 0x8016ce000 0 0 0xffffff001a0bad00 rwx 1 0 0x4 COW NC vnode /usr/local/lib/ghc-6.11.20081126/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o
0x80172b000 0x801732000 7 0 0xffffff002b24a9c0 rw- 1 0 0x2104 COW NNC vnode /libexec/ld-elf.so.1
0x801732000 0x801738000 5 0 0xffffff0033841820 rw- 1 0 0x2104 NCOW NNC default -
0x801738000 0x801748000 16 0 0xffffff00372d2750 r-x 1 0 0x2104 COW NNC vnode /lib/libthr.so.3
0x801748000 0x801749000 1 0 0xffffff002f555410 r-x 1 0 0x2104 COW NNC vnode /lib/libthr.so.3
0x801749000 0x801849000 4 0 0xffffff00052de270 r-x 218 39 0x4 COW NC vnode /lib/libthr.so.3
0x801849000 0x80184c000 3 0 0xffffff002d7b2b60 rw- 1 0 0x2104 COW NNC vnode /lib/libthr.so.3
0x80184c000 0x80184e000 2 0 0xffffff0030c72410 rw- 1 0 0x2104 NCOW NNC default -
0x80184e000 0x801859000 11 0 0xffffff0001cb29c0 r-x 174 78 0x4 COW NC vnode /lib/libutil.so.7
0x801859000 0x80185a000 1 0 0xffffff002279fb60 r-x 1 0 0x2104 COW NNC vnode /lib/libutil.so.7
0x80185a000 0x801959000 2 0 0xffffff0001cb29c0 r-x 174 78 0x4 COW NC vnode /lib/libutil.so.7
0x801959000 0x80195b000 2 0 0xffffff002f1174e0 rw- 1 0 0x2104 COW NNC vnode /lib/libutil.so.7
0x80195afff 0x80195c000 0 0 0 rw- 0 0 0x0 NCOW NNC none -
0x80195c000 0x801973000 16 0 0xffffff0001c1ec30 r-x 254 48 0x4 COW NC vnode /lib/libm.so.5
0x801973000 0x801974000 1 0 0xffffff0030f9a820 r-x 1 0 0x2104 COW NNC vnode /lib/libm.so.5
0x801974000 0x801a74000 4 0 0xffffff0001c1ec30 r-x 254 48 0x4 COW NC vnode /lib/libm.so.5
0x801a74000 0x801a76000 2 0 0xffffff0032c10270 rw- 1 0 0x2104 COW NNC vnode /lib/libm.so.5
0x801a76000 0x801a79000 3 0 0xffffff000ab1e1a0 r-x 4 2 0x4 COW NC vnode /usr/lib/librt.so.1
0x801a79000 0x801a7a000 1 0 0xffffff003721a750 r-x 1 0 0x2104 COW NNC vnode /usr/lib/librt.so.1
0x801a7a000 0x801b7a000 1 0 0xffffff000ab1e1a0 r-x 4 2 0x4 COW NC vnode /usr/lib/librt.so.1
0x801b7a000 0x801b7b000 1 0 0xffffff0033783d00 rw- 1 0 0x2104 COW NNC vnode /usr/lib/librt.so.1
0x801b7b000 0x801c60000 108 0 0xffffff0001c840d0 r-x 602 192 0x4 COW NC vnode /lib/libc.so.7
0x801c60000 0x801c61000 1 0 0xffffff001b2710d0 r-x 1 0 0x2104 COW NNC vnode /lib/libc.so.7
0x801c61000 0x801d60000 0 0 0xffffff0001c840d0 r-x 602 192 0x4 COW NC vnode /lib/libc.so.7
0x801d60000 0x801d7e000 30 0 0xffffff002277e340 rw- 1 0 0x2104 COW NNC vnode /lib/libc.so.7
0x801d7e000 0x801d94000 6 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default -
0x801e00000 0x801f00000 41 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default -
0x802000000 0x802300000 642 0 0xffffff0026ca3820 rw- 3 0 0x2104 NCOW NNC default -
0x7fffff9de000 0x7fffff9fe000 2 0 0xffffff002612bc30 rw- 1 0 0x2104 NCOW NNC default -
0x7fffffbdf000 0x7fffffbff000 2 0 0xffffff000d2cd8f0 rw- 1 0 0x2104 NCOW NNC default -
0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC none -
0x7ffffffe0000 0x800000000000 4 0 0xffffff0033d95680 rwx 1 0 0x2104 NCOW NNC default -
---- process virt. mem ----


> Also you could try doing as the error message suggests, and specify a
> different address.  e.g.
>
>   ghci +RTS -xm30000000
>   ghci +RTS -xm50000000

I tried different locations. mmap() always seems to return a address above 0x80000000,
f.e. 0x801635000, where the -xm parameter seems to have no effect.
If I sepecify a adress above 0x80000000 I get a message, that it has to be below 2GB.


Thnx and regards
Markus


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

attachment0 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Markus Barenhoff wrote:

> On Fri 28.11 09:42, Simon Marlow wrote:
>> Markus Barenhoff wrote:
>>> On Thu 27.11 09:49, Simon Marlow wrote:
>
>
> Hi!
>
>>> I checked out and translated the head version of ghc today from darcs.
>>> It compiled fine. When I now try to start the ghci I get the following:
>>>
>>> ---- snip ----
>>> GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
>>> ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for
>>> 626688 bytes at 0x40000000, got 0x801635000.  Try specifying an address
>>> with +RTS -xm<addr> -RTS
>>>    (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
>>>    Please report this as a GHC bug:  
>>>    http://www.haskell.org/ghc/reportabug
>>> Abort (core dumped)
>>> ---- snip ----
>>>
>>> If it helps somehow, you can find the core dump here:
>>> http://www.alios.org/~alios/ghc.core.bz2
>> That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working
>> fine (or is it?).
>
> yes, it worked, but I haven't installed anymore - so I'am not sure, where it
> does maps its stuff into memory.

The memory map shows that there's nothing mapped in at the place we're
asking for memory, but still FreeBSD decides to give us memory somewhere
else.  I checked back in 6.8.3 and it looks like we were using MAP_FIXED -
now MAP_FIXED is dangerous, because it will overwrite existing mappings
(like the binary itself!), which is why we're not doing that now.

I've committed a patch that uses MAP_FIXED on FreeBSD if other attempts to
get memory below 2Gb fail.  I'd be grateful if you could test it out, the
patch is this one, pushed to HEAD today:

Wed Dec 10 11:57:51 GMT 2008  Simon Marlow <[hidden email]>
   * On FreeBSD, try MAP_FIXED if ordinary mmap() fails to give us suitable
memory
   This appears to be necessary on FreeBSD.  It might be necessary on
   other OSs too, but I'm being cautious because using MAP_FIXED can lead
   to crashes by overwriting existing mappings, and we have no (easy) way
   to prevent that.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
On Wed 10.12 13:55, Simon Marlow wrote:

Hi!

> >>>I checked out and translated the head version of ghc today from darcs.
> >>>It compiled fine. When I now try to start the ghci I get the following:
> >>>
> >>>---- snip ----
> >>>GHCi, version 6.11.20081126: http://www.haskell.org/ghc/  :? for help
> >>>ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked
> >>>for 626688 bytes at 0x40000000, got 0x801635000.  Try specifying an
> >>>address with +RTS -xm<addr> -RTS
> >>>   (GHC version 6.11.20081126 for x86_64_unknown_freebsd)
> >>>    Please report this as a GHC bug:  
> >>>    http://www.haskell.org/ghc/reportabug
> >>> Abort (core dumped)
> >>>---- snip ----
> >>>
> >>>If it helps somehow, you can find the core dump here:
> >>>http://www.alios.org/~alios/ghc.core.bz2
> >>That's odd, because 6.8.3 is using 0x40000000 on FreeBSD and is working
> >>fine (or is it?).
> >
> >yes, it worked, but I haven't installed anymore - so I'am not sure, where
> >it
> >does maps its stuff into memory.
>
> The memory map shows that there's nothing mapped in at the place we're
> asking for memory, but still FreeBSD decides to give us memory somewhere
> else.  I checked back in 6.8.3 and it looks like we were using MAP_FIXED -
> now MAP_FIXED is dangerous, because it will overwrite existing mappings
> (like the binary itself!), which is why we're not doing that now.
>
> I've committed a patch that uses MAP_FIXED on FreeBSD if other attempts to
> get memory below 2Gb fail.  I'd be grateful if you could test it out, the
> patch is this one, pushed to HEAD today:
>
> Wed Dec 10 11:57:51 GMT 2008  Simon Marlow <[hidden email]>
>   * On FreeBSD, try MAP_FIXED if ordinary mmap() fails to give us suitable
> memory
>   This appears to be necessary on FreeBSD.  It might be necessary on
>   other OSs too, but I'm being cautious because using MAP_FIXED can lead
>   to crashes by overwriting existing mappings, and we have no (easy) way
>   to prevent that.
I've updated my source tree today.

But now I've problem while compiling the ghc

Here is the the build output:

[...]

/usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist-stage2/build  -H32m -O -Rghc-timing -O2  -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o  -ohi dist-stage2/build/MachRegs.p_hi
ghc: panic! (the 'impossible' happened)
  (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
        CoreToStg.myCollectArgs
    (__scc {trivColorable ghc-6.11.20081211:MachRegs !}
     ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
      eta_s2Ni{v} [lid]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

<<ghc: 303363536 bytes, 26 GCs, 4992000/12390400 avg/max bytes residency (4 samples), 40M in use, 0.00 INIT (0.00 elapsed), 0.57 MUT (0.84 elapsed), 0.25 GC (0.29 elapsed) :ghc>>
gmake[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1
gmake[3]: *** [all] Error 1
gmake[3]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler'
gmake[2]: *** [build.stage.2] Error 2
gmake[2]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc/compiler'
gmake[1]: *** [stage2] Error 2
gmake[1]: Leaving directory `/usr/home/alios/src/haskell/ghc/ghc'
gmake: *** [bootstrap2] Error 2


Regards
Markus


--
Markus Barenhoff - Langemarckstr. 18 - D-48147 Münster - Germany - Europe - Earth
Tel. +49-251-3956651 - Mob. +49-173-7215776 - e-mail: [hidden email]
jabber: [hidden email] - icq: 27998346


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

attachment0 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Markus Barenhoff wrote:

> I've updated my source tree today.
>
> But now I've problem while compiling the ghc
>
> Here is the the build output:
>
> [...]
>
> /usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.
5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist-stage2/build  -H32m -O -Rghc-timing -O2  -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o  -ohi dist-stage2/build/MachRegs.p_hi
> ghc: panic! (the 'impossible' happened)
>   (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
>         CoreToStg.myCollectArgs
>     (__scc {trivColorable ghc-6.11.20081211:MachRegs !}
>      ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
>       eta_s2Ni{v} [lid]
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This is a known problem with the build right now.  I'll try to install a
fix this week, but in the meantime you can avoid building profiled
libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the
line that says 'BuildFlavour = quick'.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
On Mon 15.12 09:26, Simon Marlow wrote:


Hello everyone,

a happy new year first of all.

> 5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package
> template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
> -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash
> -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls
> -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances
> -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi
> -hcsuf p_hc -osuf p_o -idist-stage2/build  -H32m -O -Rghc-timing -O2  -c
> nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o  -ohi
> dist-stage2/build/MachRegs.p_hi
> >ghc: panic! (the 'impossible' happened)
> >  (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
> >        CoreToStg.myCollectArgs
> >    (__scc {trivColorable ghc-6.11.20081211:MachRegs !}
> >     ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
> >      eta_s2Ni{v} [lid]
> >
> >Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> This is a known problem with the build right now.  I'll try to install a
> fix this week, but in the meantime you can avoid building profiled
> libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the
> line that says 'BuildFlavour = quick'.
>
Yesterday I updated my sources to the current darcs version. Now the build works
again, but there still seems to exist a problem with memory allocation:

--- snip ---
 $ ghci
 GHCi, version 6.11.20090105: http://www.haskell.org/ghc/  :? for help
 ghc: mmap 28672 bytes at 0x40099000: Invalid argument
 ghc: Try specifying an address with +RTS -xm<addr> -RTS
--- snip ---

The ghci does not coredump anymore like it did in my first posting.
I also tried specifing different addresses with the -xm switch without success.

Here is the memory map just after start:

--- snip ---
$ cat /proc/19219/map
0x400000 0x14f8000 4213 0 0xffffff0006094d00 r-x 1 0 0x2100 COW NNC vnode /usr/local/haskell/lib/ghc-6.11.20090105/ghc
0x15f7000 0x178a000 251 0 0xffffff000618dd00 rw- 1 0 0x2100 COW NNC vnode /usr/local/haskell/lib/ghc-6.11.20090105/ghc
0x178a000 0x178e000 3 0 0xffffff00370a6dd0 rw- 2 0 0x2100 NCOW NNC default -
0x178e000 0x1800000 1 0 0xffffff00370a6dd0 rwx 2 0 0x2100 NCOW NNC default -
0x8015f7000 0x80161c000 28 0 0xffffff003af6f8f0 r-x 1 0 0x2100 COW NNC vnode /libexec/ld-elf.so.1
0x80161c000 0x801624000 7 0 0xffffff000618da90 rw- 1 0 0x2100 NCOW NNC default -
0x80171b000 0x801722000 7 0 0xffffff0037db6680 rw- 1 0 0x2100 COW NNC vnode /libexec/ld-elf.so.1
0x801722000 0x801728000 6 0 0xffffff00062de680 rw- 1 0 0x2100 NCOW NNC default -
0x801728000 0x801738000 16 0 0xffffff002ed375b0 r-x 1 0 0x2100 COW NNC vnode /lib/libthr.so.3
0x801738000 0x801739000 1 0 0xffffff003a5d2410 r-x 1 0 0x2100 COW NNC vnode /lib/libthr.so.3
0x801739000 0x801839000 4 0 0xffffff0001caa000 r-x 172 41 0x4 COW NC vnode /lib/libthr.so.3
0x801839000 0x80183c000 3 0 0xffffff000621d820 rw- 1 0 0x2100 COW NNC vnode /lib/libthr.so.3
0x80183c000 0x80183e000 2 0 0xffffff0037f9aa90 rw- 1 0 0x2100 NCOW NNC default -
0x80183e000 0x801849000 9 0 0xffffff00015c2c30 r-x 166 74 0x4 COW NC vnode /lib/libutil.so.7
0x801849000 0x80184a000 1 0 0xffffff00061e5680 r-x 1 0 0x2100 COW NNC vnode /lib/libutil.so.7
0x80184a000 0x80194a000 3 0 0xffffff00015c2c30 r-x 166 74 0x4 COW NC vnode /lib/libutil.so.7
0x80194a000 0x80194c000 2 0 0xffffff00061e5820 rw- 1 0 0x2100 COW NNC vnode /lib/libutil.so.7
0x80194c000 0x80194d000 0 0 0 rw- 0 0 0x0 NCOW NNC none -
0x80194d000 0x801965000 17 0 0xffffff00015ee0d0 r-x 204 48 0x4 COW NC vnode /lib/libm.so.5
0x801965000 0x801966000 1 0 0xffffff00061ae000 r-x 1 0 0x2100 COW NNC vnode /lib/libm.so.5
0x801966000 0x801a65000 3 0 0xffffff00015ee0d0 r-x 204 48 0x4 COW NC vnode /lib/libm.so.5
0x801a65000 0x801a67000 2 0 0xffffff003a102750 rw- 1 0 0x2100 COW NNC vnode /lib/libm.so.5
0x801a67000 0x801a6a000 3 0 0xffffff0001cf2680 r-x 8 4 0x4 COW NC vnode /usr/lib/librt.so.1
0x801a6a000 0x801a6b000 1 0 0xffffff000618e000 r-x 1 0 0x2100 COW NNC vnode /usr/lib/librt.so.1
0x801a6b000 0x801b6b000 1 0 0xffffff0001cf2680 r-x 8 4 0x4 COW NC vnode /usr/lib/librt.so.1
0x801b6b000 0x801b6c000 1 0 0xffffff0031604270 rw- 1 0 0x2100 COW NNC vnode /usr/lib/librt.so.1
0x801b6c000 0x801c57000 93 0 0xffffff00015c2270 r-x 512 182 0x4 COW NC vnode /lib/libc.so.7
0x801c57000 0x801c58000 1 0 0xffffff00312f0820 r-x 1 0 0x2100 COW NNC vnode /lib/libc.so.7
0x801c58000 0x801d58000 0 0 0xffffff00015c2270 r-x 512 182 0x4 COW NC vnode /lib/libc.so.7
0x801d58000 0x801d75000 29 0 0xffffff000631e340 rw- 1 0 0x2100 COW NNC vnode /lib/libc.so.7
0x801d75000 0x801d8c000 5 0 0xffffff0006248270 rw- 2 0 0x2100 NCOW NNC default -
0x801e00000 0x801f00000 3 0 0xffffff0006248270 rw- 2 0 0x2100 NCOW NNC default -
0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC none -
0x7ffffffe0000 0x800000000000 3 0 0xffffff00061704e0 rwx 1 0 0x2100 NCOW NNC default -
--- snip ---

Regards
Markus

--
Markus Barenhoff - Münster - Germany - Europe - Earth


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

attachment0 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Markus Barenhoff wrote:

> On Mon 15.12 09:26, Simon Marlow wrote:
>
>
> Hello everyone,
>
> a happy new year first of all.
>
>> 5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package
>> template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
>> -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash
>> -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls
>> -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances
>> -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi
>> -hcsuf p_hc -osuf p_o -idist-stage2/build  -H32m -O -Rghc-timing -O2  -c
>> nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o  -ohi
>> dist-stage2/build/MachRegs.p_hi
>>> ghc: panic! (the 'impossible' happened)
>>>  (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
>>>        CoreToStg.myCollectArgs
>>>    (__scc {trivColorable ghc-6.11.20081211:MachRegs !}
>>>     ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
>>>      eta_s2Ni{v} [lid]
>>>
>>> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>> This is a known problem with the build right now.  I'll try to install a
>> fix this week, but in the meantime you can avoid building profiled
>> libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the
>> line that says 'BuildFlavour = quick'.
>>
>
> Yesterday I updated my sources to the current darcs version. Now the build works
> again, but there still seems to exist a problem with memory allocation:
>
> --- snip ---
>  $ ghci
>  GHCi, version 6.11.20090105: http://www.haskell.org/ghc/  :? for help
>  ghc: mmap 28672 bytes at 0x40099000: Invalid argument
>  ghc: Try specifying an address with +RTS -xm<addr> -RTS
> --- snip ---

Could you run ktrace or truss on ghci so we can see the offending call to
mmap()?  I'm not sure what it is that the OS is complaining about.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff-2
On Thu 08.01 12:22, Simon Marlow wrote:

> Markus Barenhoff wrote:
> >On Mon 15.12 09:26, Simon Marlow wrote:
> >Yesterday I updated my sources to the current darcs version. Now the build
> >works
> >again, but there still seems to exist a problem with memory allocation:
> >
> >--- snip ---
> > $ ghci
> > GHCi, version 6.11.20090105: http://www.haskell.org/ghc/  :? for help
> > ghc: mmap 28672 bytes at 0x40099000: Invalid argument
> > ghc: Try specifying an address with +RTS -xm<addr> -RTS
> >--- snip ---
>
> Could you run ktrace or truss on ghci so we can see the offending call to
> mmap()?  I'm not sure what it is that the OS is complaining about.
>
it looks like it is trying to mmap() stdin...

attached you find the complete trace.

--- snip ---
...
38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
38437: open("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",O_RDONLY,00) = 6 (0x6)
38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE,6,0x0) = 34382954496 (0x801624000)
38437: munmap(0x801624000,626688)                = 0 (0x0)
38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,6,0x0) = 1073741824 (0x40000000)
38437: close(6)                                  = 0 (0x0)
38437: mmap(0x40099000,28672,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0,0x0) ERR#22 'Invalid argument'
38437: write(2,"ghc: ",5)                        = 5 (0x5)
38437: write(2,"mmap 28672 bytes at 0x40099000",30) = 30 (0x1e)
38437: write(2,": Invalid argument\n",19)        = 19 (0x13)
38437: write(2,"ghc: ",5)                        = 5 (0x5)
38437: write(2,"Try specifying an address with +"...,50) = 50 (0x32)
38437: SIGNAL 14 (SIGALRM)
38437: sigreturn(0x7fffff9fd9f0,0x0,0x0,0x2b,0x0,0x7fffff9fd9e0) ERR#4 'Interrupted system call'
38437: write(2,"\n",1)                           = 1 (0x1)
38437: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGABRT|SIGEMT|SIGKILL|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
38437: sigprocmask(SIG_SETMASK,0x0,0x0)          = 0 (0x0)
38437: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGABRT|SIGEMT|SIGKILL|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
38437: sigprocmask(SIG_SETMASK,0x0,0x0)          = 0 (0x0)
38437: process exit, rval = 1
--- snip ---

regards
markus

--
Markus Barenhoff - Langemarckstr. 18 - D-48147 Münster - Germany - Europe - Earth
Tel. +49-251-3956651 - Mob. +49-173-7215776 - e-mail: [hidden email]
jabber: [hidden email] - icq: 27998346


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghci.truss (47K) Download Attachment
attachment1 (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Markus Barenhoff wrote:

> On Thu 08.01 12:22, Simon Marlow wrote:
>> Markus Barenhoff wrote:
>>> On Mon 15.12 09:26, Simon Marlow wrote:
>>> Yesterday I updated my sources to the current darcs version. Now the build
>>> works
>>> again, but there still seems to exist a problem with memory allocation:
>>>
>>> --- snip ---
>>> $ ghci
>>> GHCi, version 6.11.20090105: http://www.haskell.org/ghc/  :? for help
>>> ghc: mmap 28672 bytes at 0x40099000: Invalid argument
>>> ghc: Try specifying an address with +RTS -xm<addr> -RTS
>>> --- snip ---
>> Could you run ktrace or truss on ghci so we can see the offending call to
>> mmap()?  I'm not sure what it is that the OS is complaining about.
>>
>
> it looks like it is trying to mmap() stdin...
>
> attached you find the complete trace.
>
> --- snip ---
> ...
> 38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
> 38437: stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{ mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
> 38437: open("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",O_RDONLY,00) = 6 (0x6)
> 38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE,6,0x0) = 34382954496 (0x801624000)
> 38437: munmap(0x801624000,626688)                = 0 (0x0)
> 38437: mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,6,0x0) = 1073741824 (0x40000000)
> 38437: close(6)                                  = 0 (0x0)
> 38437: mmap(0x40099000,28672,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0,0x0) ERR#22 'Invalid argument'

Ah, I think I see the problem.  FreeBSD requires the fd argument to be -1
for MAP_ANON, but Linux doesn't care which is why it didn't fail in this
way for me.  I'll commit a patch as soon as it validates.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Simon Marlow-7
Simon Marlow wrote:

> Markus Barenhoff wrote:
>> On Thu 08.01 12:22, Simon Marlow wrote:
>>> Markus Barenhoff wrote:
>>>> On Mon 15.12 09:26, Simon Marlow wrote:
>>>> Yesterday I updated my sources to the current darcs version. Now the
>>>> build works
>>>> again, but there still seems to exist a problem with memory allocation:
>>>>
>>>> --- snip ---
>>>> $ ghci
>>>> GHCi, version 6.11.20090105: http://www.haskell.org/ghc/  :? for help
>>>> ghc: mmap 28672 bytes at 0x40099000: Invalid argument
>>>> ghc: Try specifying an address with +RTS -xm<addr> -RTS
>>>> --- snip ---
>>> Could you run ktrace or truss on ghci so we can see the offending
>>> call to mmap()?  I'm not sure what it is that the OS is complaining
>>> about.
>>>
>>
>> it looks like it is trying to mmap() stdin...
>>
>> attached you find the complete trace.
>>
>> --- snip ---
>> ...
>> 38437:
>> stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{
>> mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
>> 38437:
>> stat("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",{
>> mode=-rw-r--r-- ,inode=284783,size=623896,blksize=4096 }) = 0 (0x0)
>> 38437:
>> open("/usr/local/haskell/lib/ghc-6.11.20090105/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o",O_RDONLY,00)
>> = 6 (0x6)
>> 38437:
>> mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE,6,0x0)
>> = 34382954496 (0x801624000)
>> 38437: munmap(0x801624000,626688)                = 0 (0x0)
>> 38437:
>> mmap(0x40000000,626688,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED,6,0x0)
>> = 1073741824 (0x40000000)
>> 38437: close(6)                                  = 0 (0x0)
>> 38437:
>> mmap(0x40099000,28672,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0,0x0)
>> ERR#22 'Invalid argument'
>
> Ah, I think I see the problem.  FreeBSD requires the fd argument to be
> -1 for MAP_ANON, but Linux doesn't care which is why it didn't fail in
> this way for me.  I'll commit a patch as soon as it validates.

Patch pushed... I'd be grateful if you could test it - thanks!

Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users