Rahul Kapoor wrote:

...

Are you running under Xen by any chance? Yes I am. This is on a SliceHost instance.

Is there a tentative release date for 6.10.2?

About 3 months after the 6.10.1 release was the tentative plan. Is anyone with access to a Xen instance able to work on this bug? It would need a hack similar to the one required for http://hackage.haskell.org/trac/ghc/ticket/2063 namely picking an area of the address space to try to mmap() from. (of course, ideally the Xen folks would fix their kernel to respect MAP_32BIT...) Cheers, Simon

HEAD 2008/11/18 Rahul Kapoor :

...

I've made a speculative fix. If you're able to test it, that would be very helpful: I imagine, I need to download the nightly snapshot and build it. HEAD or STABLE?

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

-- Push the envelope. Watch it bend.

Rahul Kapoor wrote:

...

I've made a speculative fix. If you're able to test it, that would be very helpful:

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

Cheers, Simon

I had no luck installing the binary snapshot (libedit problems, which I worked around by creating a link to the version I had) after which I started get libc version problems so I gave up on that built the HEAD snapshot from source.

running ghci in-place now gives:

GHCi, version 6.11.20081117: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. ghc: internal error: loadObj: failed to mmap() memory below 2Gb; asked for 57344 bytes at 0x0x4009fa00, got 0x0x7f3a9b2b8000. Try specifying an address with +RTS -xm<addr> -RTS (GHC version 6.11.20081117 for x86_64_unknown_linux)

I am not really sure what I <addr> for -xm should be.

Ok, so we got a bit further, but it looks like at some point mmap() stopped giving us memory where we wanted it, perhaps because something else was already mapped at that address. It would be useful to get a look at the memory map. Can you load up GHCi in gdb, as follows. First, find out the path to your GHC binary and the -B option it needs: $ cat `which ghc` #!/bin/sh exec /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. -dynload wrapped ${1+"$@"} Here, /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc is my GHC binary, and -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. is the option I need to pass. Now start gdb: $ gdb /home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/ghc and run GHC: (gdb) run --interactive -B/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.1/. It will now crash with the error you saw above. At this point we need to look at the memory map. Find the PID of the GHC process, by running 'ps uxw' in a terminal (don't quit gdb). Then $ cat /proc/<pid>/maps where <pid> is the PID of the GHC process running in gdb, and send me the output. Cheers, Simon

Rahul Kapoor wrote:

Attached is the memory map of ghc process running under gdb on a xen instance.

Thanks! I think I see the bug. I've just pushed another patch ("round the size up to a page in mmapForLinker() instead of in the caller"), if you could try it out that would be great. Cheers, Simon

Rahul Kapoor wrote:

...

Thanks! I think I see the bug. I've just pushed another patch ("round the size up to a page in mmapForLinker() instead of in the caller"), if you could try it out that would be great.

ghci from ghc-6.11.20081120 works without problems on my xen instance!

Nice! Thanks for helping out. Cheers, Simon