current build blocks indefinitely

Matthias Neubauer neubauer at informatik.uni-freiburg.de
Fri Feb 18 16:19:22 EST 2005


Hi all,

I just grabbed the current cvs version of GHC and tried to build
it. Strangely enough, as soon as the first compiled haskell program
gets executed it seems to block indefinitely. Here is a log of the
last part of my build process until it blocks:

[...]
make[3]: Nothing to be done for `boot'.
------------------------------------------------------------------------
===fptools== Finished making `boot' in users_guide ext-core storage-mgt ...
PWD = /scratch/mn/ghc-6.4-for-ghc-package-i386-debian/ghc/docs
------------------------------------------------------------------------
------------------------------------------------------------------------
==fptools== make boot -wr;
 in /scratch/mn/ghc-6.4-for-ghc-package-i386-debian/ghc/compiler
------------------------------------------------------------------------
../../glafp-utils/mkdirhier/mkdirhier stage1
for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn specialise simplCore stranal stgSyn simplStg codeGen main profiling parser cprAnalysis compMan ndpFlatten iface cmm nativeGen; do \
    ../../glafp-utils/mkdirhier/mkdirhier stage1/$i; \
done
for i in */*hi-boot*; do \
    ln -s -f ../../$i stage1/$i || true ; \
done
../utils/genprimopcode/genprimopcode --primop-tag         < prelude/primops.txt > primop-tag.hs-incl


Calling the last command manually via strace leads to the following output ...


paaulau:/<3>ghc/compiler> strace -f ../utils/genprimopcode/genprimopcode --primop-tag         < prelude/primops.txt > primop-tag.hs-incl

[...]
write(1, "PrimOp ReadByteArrayOp_Addr = _I"..., 8192) = 8192 
mmap2(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40400000 
mprotect(0x40400000, 4096, PROT_NONE)   = 0 
clone(Process 15997 attached 
child_stack=0x40bffb48, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_\
CLEARTID|CLONE_DETACHED, parent_tidptr=0x40bffbf8, {entry_number:6, base_addr:0x40bffbb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0\
, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x40bffbf8) = 15997 
[pid 15996] times({tms_utime=7, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 821448934 
[pid 15996] mmap2(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40c00000 
[pid 15996] mprotect(0x40c00000, 4096, PROT_NONE) = 0 
[pid 15996] clone(Process 15998 attached 
child_stack=0x413ffb48, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_\
CLEARTID|CLONE_DETACHED, parent_tidptr=0x413ffbf8, {entry_number:6, base_addr:0x413ffbb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0\
, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x413ffbf8) = 15998 
[pid 15996] futex(0x80b0274, FUTEX_WAIT, 0, NULL <unfinished ...> 
[pid 15997] write(1, ") :: FastInt\ntagOf_PrimOp DeRefS"..., 919 <unfinished ...> 
[pid 15998] futex(0x80a43e4, FUTEX_WAIT, 0, NULL <unfinished ...> 
[pid 15997] <... write resumed> )       = 919 
[pid 15997] futex(0x80b0274, FUTEX_REQUEUE, 1, 2147483647, 0x80a3998 <unfinished ...> 
[pid 15996] <... futex resumed> )       = 0 
[pid 15997] <... futex resumed> )       = 1 
[pid 15996] futex(0x80a3998, FUTEX_WAIT, 2, NULL <unfinished ...> 
[pid 15997] gettimeofday({1108760364, 365240}, NULL) = 0 
[pid 15997] pipe([3, 4])                = 0 
[pid 15997] futex(0x80a3998, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15996] <... futex resumed> )       = 0 
[pid 15997] <... futex resumed> )       = 1 
[pid 15996] futex(0x80a3998, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15997] select(4, [3], [], NULL, {134, 217727} <unfinished ...> 
[pid 15996] <... futex resumed> )       = 0 
[pid 15996] write(4, "*", 1 <unfinished ...> 
[pid 15997] <... select resumed> )      = 1 (in [3], left {134, 218000}) 
[pid 15996] <... write resumed> )       = 1 
[pid 15997] futex(0x80a3998, FUTEX_WAIT, 2, NULL <unfinished ...> 
[pid 15996] futex(0x80a3998, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15997] <... futex resumed> )       = -1 EAGAIN (Resource temporarily unavailable) 
[pid 15996] <... futex resumed> )       = 0 
[pid 15997] read(3,  <unfinished ...> 
[pid 15996] futex(0x80a43d4, FUTEX_WAIT, 0, NULL <unfinished ...> 
[pid 15997] <... read resumed> "*", 1)  = 1 
[pid 15997] futex(0x80a43d4, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15996] <... futex resumed> )       = 0 
[pid 15997] <... futex resumed> )       = 1 
[pid 15996] futex(0x80a43c4, FUTEX_WAIT, 2, NULL <unfinished ...> 
[pid 15997] futex(0x80a43c4, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15996] <... futex resumed> )       = -1 EAGAIN (Resource temporarily unavailable) 
[pid 15997] <... futex resumed> )       = 0 
[pid 15996] futex(0x80a43c4, FUTEX_WAKE, 1 <unfinished ...> 
[pid 15997] futex(0x80a43d4, FUTEX_WAIT, 2, NULL <unfinished ...> 
[pid 15996] <... futex resumed> )       = 0 
[pid 15996] futex(0x80a43d4, FUTEX_WAIT, 1, NULL) = -1 EAGAIN (Resource temporarily unavailable) 
[pid 15996] futex(0x80a43d4, FUTEX_WAIT, 2, NULL 


This all happens on one of our Linux boxes running under Debian btw ...

paaulau:/<3>ghc/compiler> uname -a
Linux paaulau 2.6.8-1-386 #1 Thu Nov 11 12:18:43 EST 2004 i686 GNU/Linux

... where apparently the tls versions of shared libraries are loaded first ...

paaulau:/<3>ghc/compiler> ldd ../utils/genprimopcode/genprimopcode
                libm.so.6 => /lib/tls/libm.so.6 (0x40019000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4003c000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40069000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4006c000)
        libc.so.6 => /lib/tls/libc.so.6 (0x4007b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Anybody seen this before?

-Matthias

-- 
Matthias Neubauer                                       |
Universität Freiburg, Institut für Informatik           | tel +49 761 203 8060
Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052



More information about the Glasgow-haskell-bugs mailing list