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

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....

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

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 * 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 <> 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: alios@alios.org jabber: alios@jabber.ccc.de - icq: 27998346

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

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: alios@alios.org jabber: alios@jabber.ccc.de - icq: 27998346

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