[GHC] #10298: Infinite loop when shared libraries are unavailable

[GHC]

#10298: Infinite loop when shared libraries are unavailable
-------------------------------------+-------------------------------------
        Reporter:  snoyberg          |                   Owner:  simonmar
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Runtime System    |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Linux             |            Architecture:  x86_64
 Type of failure:  Runtime crash     |  (amd64)
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
Description changed by simonpj:

Old description:

> Originally discussed at: https://groups.google.com/d/msg/haskell-
> cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as
> a static linking and Docker issue, but in fact affects dynamically linked
> executables without any containerization.
>
> I've put together the following script that reproduces my problem:
>
> {{{
> cat > hello.hs <<EOF
> main :: IO ()
> main = putStrLn "Hello World"
> EOF
> ghc hello.hs
>
> rm -rf tmp
> mkdir tmp
>
> cp hello tmp
>
> mkdir -p tmp/usr/lib/x86_64-linux-gnu
> cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu
>
> mkdir -p tmp/lib/x86_64-linux-gnu
> cp \
>     /lib/x86_64-linux-gnu/libm.so.6 \
>     /lib/x86_64-linux-gnu/librt.so.1 \
>     /lib/x86_64-linux-gnu/libdl.so.2 \
>     /lib/x86_64-linux-gnu/libc.so.6 \
>     /lib/x86_64-linux-gnu/libpthread.so.0 \
>     tmp/lib/x86_64-linux-gnu
>
> mkdir -p tmp/lib64
> cp /lib64/ld-linux-x86-64.so.2 tmp/lib64
>
> #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/
> #cp \
> #    /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \
> #    /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \
> #    tmp/usr/lib/x86_64-linux-gnu/gconv
>
> sudo chroot tmp /hello
> }}}
>
> If I uncomment the block that copies the gconv files, the program runs as
> expected. However, without those files copied, the program burns CPU and
> consumes memory until killed by the OS. I ran strace on a similar
> executable, and got the results at:
>
> https://gist.github.com/snoyberg/095efb17e36acc1d6360
>
> Note that this problem also occurs with statically linked executables
> when some of the other dynamically linked libraries are not available in
> the chroot environment.
>
> Expected behavior: ideal would be not to require the gconv files and
> other shared libraries be present, especially when statically linked.
> Barring that, it would be much better if the RTS could produce a
> meaningful error message about the missing file. Note that strace does
> demonstrate that a open system call is failing, e.g.:
>
> open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) =
> -1 ENOENT (No such file or directory)
>
> Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit.

New description:

 Originally discussed at: https://groups.google.com/d/msg/haskell-
 cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as
 a static linking and Docker issue, but in fact affects dynamically linked
 executables without any containerization.

 Other examples of the same bug: #7695, #8977, #8928

 I've put together the following script that reproduces my problem:

 {{{
 cat > hello.hs <<EOF
 main :: IO ()
 main = putStrLn "Hello World"
 EOF
 ghc hello.hs

 rm -rf tmp
 mkdir tmp

 cp hello tmp

 mkdir -p tmp/usr/lib/x86_64-linux-gnu
 cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu

 mkdir -p tmp/lib/x86_64-linux-gnu
 cp \
     /lib/x86_64-linux-gnu/libm.so.6 \
     /lib/x86_64-linux-gnu/librt.so.1 \
     /lib/x86_64-linux-gnu/libdl.so.2 \
     /lib/x86_64-linux-gnu/libc.so.6 \
     /lib/x86_64-linux-gnu/libpthread.so.0 \
     tmp/lib/x86_64-linux-gnu

 mkdir -p tmp/lib64
 cp /lib64/ld-linux-x86-64.so.2 tmp/lib64

 #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/
 #cp \
 #    /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \
 #    /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \
 #    tmp/usr/lib/x86_64-linux-gnu/gconv

 sudo chroot tmp /hello
 }}}

 If I uncomment the block that copies the gconv files, the program runs as
 expected. However, without those files copied, the program burns CPU and
 consumes memory until killed by the OS. I ran strace on a similar
 executable, and got the results at:

 https://gist.github.com/snoyberg/095efb17e36acc1d6360

 Note that this problem also occurs with statically linked executables when
 some of the other dynamically linked libraries are not available in the
 chroot environment.

 Expected behavior: ideal would be not to require the gconv files and other
 shared libraries be present, especially when statically linked. Barring
 that, it would be much better if the RTS could produce a meaningful error
 message about the missing file. Note that strace does demonstrate that a
 open system call is failing, e.g.:

 open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1
 ENOENT (No such file or directory)

 Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10298#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler