Trouble with ghc on linux x86_64

The system is a xen virtual machine: Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux With GHC version 6.8.2, ghci gives the error: $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f10a29e56d0 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted GHC version 6.10.1 gives a similar error: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted These same 2 results happen on 2 different distros that I've tried. With both GHC versions, compiling haskell programs sometimes works, but sometimes hangs during the linking stage. The results are the same using the distro provided packages and with the binaries from the ghc website. I also actually managed to compile ghc version 6.10.1 using ghc 6.8.2, but not completely, "make" got froze during haddock generation for ghc-6.10.1. There was however a "ghc" binary that was produced in the directory ghc/dist-stage2/build/ghc/ghc. Running this binary as --interactive gave the exact same 6.10.1 error above. Any ideas? Thanks, Bit

Bit Connor wrote:
The system is a xen virtual machine: Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux
With GHC version 6.8.2, ghci gives the error:
$ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f10a29e56d0
(GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted
Yes, this is a known bug. Xen doesn't respect the MAP_32BIT flag to mmap(), which GHC on x86_64 relies on. http://hackage.haskell.org/trac/ghc/ticket/2512
GHC version 6.10.1 gives a similar error:
$ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted
These same 2 results happen on 2 different distros that I've tried. With both GHC versions, compiling haskell programs sometimes works, but sometimes hangs during the linking stage.
Compiling and running executables should work fine, only GHCi is affected by the above bug. Could you try -v when linking and see what stage is hanging? Cheers, Simon

On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow
Compiling and running executables should work fine, only GHCi is affected by the above bug. Could you try -v when linking and see what stage is hanging?
Here is an example with a standard cabal Setup.lhs file. It outputs the following and then hangs. When I look at "top" then there is an "ld" process taking up almost zero cpu, but hundreds of MB of memory. $ ghc -v --make Setup.lhs Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Setup.lhs Created temporary directory: /tmp/ghc3404_0 *** Literate pre-processor: /usr/lib/ghc-6.8.2/unlit -h Setup.lhs Setup.lhs /tmp/ghc3404_0/ghc3404_0.lpp Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Wed Dec 26 03:40:53 PST 2007 ms_mod = main:Main, ms_imps = [Distribution.Simple] ms_srcimps = [] }] compile: input file /tmp/ghc3404_0/ghc3404_0.lpp *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 8 *** Simplify: Result size = 6 Result size = 6 *** Tidy Core: Result size = 6 writeBinIface: 1 Names writeBinIface: 17 dict entries *** CorePrep: Result size = 6 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /tmp/ghc3404_0/ghc3404_0.s -o Setup.o *** Deleting temp files: Deleting: /tmp/ghc3404_0/ghc3404_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Fri Nov 14 07:13:35 PST 2008) main:Main [DotO Setup.o] Linking Setup ... *** Linker: gcc -v -o Setup Setup.o -L/usr/lib/ghc-6.8.2/lib/Cabal-1.2.3.0 -L/usr/lib/ghc-6.8.2/lib/containers-0.1.0.1 -L/usr/lib/ghc-6.8.2/lib/array-0.1.0.0 -L/usr/lib/ghc-6.8.2/lib/process-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/unix-2.3.0.0 -L/usr/lib/ghc-6.8.2/lib/directory-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/filepath-1.1.0.0 -L/usr/lib/ghc-6.8.2/lib/old-time-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/old-locale-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/pretty-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/base-3.0.1.0 -L/usr/lib/ghc-6.8.2 -lHSCabal-1.2.3.0 -lHScontainers-0.1.0.1 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -lutil -ldl -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSpretty-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.3 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib/ld-linux-x86-64.so.2 -o Setup -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/ghc-6.8.2/lib/Cabal-1.2.3.0 -L/usr/lib/ghc-6.8.2/lib/containers-0.1.0.1 -L/usr/lib/ghc-6.8.2/lib/array-0.1.0.0 -L/usr/lib/ghc-6.8.2/lib/process-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/unix-2.3.0.0 -L/usr/lib/ghc-6.8.2/lib/directory-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/filepath-1.1.0.0 -L/usr/lib/ghc-6.8.2/lib/old-time-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/old-locale-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/pretty-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/base-3.0.1.0 -L/usr/lib/ghc-6.8.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../.. Setup.o -lHSCabal-1.2.3.0 -lHScontainers-0.1.0.1 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -lutil -ldl -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSpretty-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../lib/crtn.o

Bit Connor wrote:
On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow
wrote: Compiling and running executables should work fine, only GHCi is affected by the above bug. Could you try -v when linking and see what stage is hanging?
Here is an example with a standard cabal Setup.lhs file. It outputs the following and then hangs. When I look at "top" then there is an "ld" process taking up almost zero cpu, but hundreds of MB of memory.
Since it seems to be hanging in the linker, and this is a Xen instance, perhaps you're running out of memory and swapping? BTW, I've checked in a potential fix for the mmap() problem you reported earlier, see http://hackage.haskell.org/trac/ghc/ticket/2063 Cheers, Simon
participants (2)
-
Bit Connor
-
Simon Marlow