Update: Re: Hurd stabilty: compiling ghc6

[Svante Signell]

On Mon, 2011-04-04 at 12:35 +0200, Svante Signell wrote:
> On Wed, 2011-03-30 at 11:13 +0200, Samuel Thibault wrote:
> > Svante Signell, le Wed 30 Mar 2011 09:18:05 +0200, a écrit :
> > > (I don't think the problem is due to qemu-kvm?)
...
> Below is the limited information provided by gdb:

Update: The problem seems to be hurd related not due to kvm.

I have now tried ghc6-6.10.1-{1 to 5} using the successfully built
6.8.2dfsg1-1.1 (latest in 6.8 series) with different splitobjs,
profiler, debug and thread parameters. The hang is always at the same
place! I even tried to replace dash with bash, no difference.

I'm soon running out of steam for this task..., why did I start this?

The build always hangs at configuring libraries/random-1.0.0.1 with
cabal-bin: .../ghc6-6.10.1+dfsg1/libraries/cabal-bin
(random is the second last library before stage1 is complete)

.../cabal-bin ...a long set of parameters... --verbose=3
Configuring random-1.0.0.1...
Creating dist (and its parents)
(".../ghc6-6.10.1+dfsg1/ghc/stage1-inplace/ghc",["--numeric-version"])
.../ghc6-6.10.1+dfsg1/ghc/stage1-inplace/ghc is version 6.10.1
(".../ghc6-6.10.1dfsg1/utils/ghc-pkg/install-inplace/bin/ghc-pkg",["--version"])
.../ghc6-6.10.1+dfsg1/utils/ghc-pkg/install-inplace/bin/ghc-pkg
is version 6.10.1
(".../ghc/stage1-inplace/ghc",["--supported-languages"])
Reading installed packages...
(".../utils/ghc-pkg/install-inplace/bin/ghc-pkg",["dump","--global"])

Hang happens here!

I've asked at Haskell mailing lists, so far nobody could help.
Running the command ghc-pkg script manually works OK!
../utils/ghc-pkg/install-inplace/bin/ghc-pkg
--global-conf /path/to/package.conf "dump" "--global"

ldd cabal-bin:
        libutil.so.1 => /lib/libutil.so.1 (0x01031000)
        libdl.so.2 => /lib/libdl.so.2 (0x01035000)
        libm.so.6 => /lib/libm.so.6 (0x01039000)
        libgmp.so.10 => /usr/lib/libgmp.so.10 (0x01060000)
        librt.so.1 => /lib/librt.so.1 (0x010d5000)
        libc.so.0.3 => /lib/libc.so.0.3 (0x010d9000)
        /lib/ld.so => /lib/ld.so.1 (0x00001000)
        libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x0126c000)
        libmachuser.so.1 => /lib/libmachuser.so.1 (0x0127a000)
        libhurduser.so.0.3 => /lib/libhurduser.so.0.3 (0x01292000)
        libihash.so.0.3 => /lib/libihash.so.0.3 (0x012b8000)

Below is the backtrace with debug versions if libc, hurd and gnumach
installed:
(gdb) bt
#0  0x011120dc in _hurd_intr_rpc_msg_in_trap (msg=0x15ff0dc, option=3,
send_size=44, rcv_size=2092, rcv_name=82, timeout=0, notify=0) at
intr-msg.c:134
#1  0x012aa195 in __io_read (io_object=108, data=0x15ff9e8,
dataCnt=0x15ff9ec, offset=-1, amount=8192)
at 
/home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.11.2/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:138
#2  0x01116b61 in readfd (port=108) at fd-read.c:34
#3  0x0111da29 in _hurd_ctty_input (port=108, ctty=0, rpc=0x15ff9f4)
    at ctty-input.c:32
#4  0x011164ee in _hurd_fd_read (fd=0x27dc8, buf=0x14f008, offset=-1) at
fd-read.c:39
#5  0x011d3ce0 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjuction with DW_OP_piece
or DW_OP_bit_piece.
) at ../sysdeps/mach/hurd/read.c:27
#6  0x084919c8 in s9qJ_ret ()
#7  0x0861f842 in StgRun ()
#8  0x087c44e0 in ?? ()