Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,323
    • Issues 4,323
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 388
    • Merge Requests 388
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10298

Closed
Open
Opened Apr 14, 2015 by Michael Snoyman@snoyberg

Infinite loop when shared libraries are unavailable

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 (closed), #8977 (closed), #8928 (closed)

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.

Edited Mar 10, 2019 by thoughtpolice
Assignee
Assign to
7.10.2
Milestone
7.10.2 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#10298