building with docker seems utterly broken

[angerman]

Using a debian 8.3 docker image, to build a haskell project targeting linux on mac, using

• stack 1.0.4.3
• docker-machine 0.6.0
• docker 1.10.2

and

• lts-5.13

I'm getting the following error (varying value for closure type) for many packages

    setup-Simple-Cabal-1.22.5.0-ghc-7.10.3:
    '~/.stack/programs/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/ghc-7.10.3/bin/ghc'
    exited with an error:
    ghc: internal error: evacuate(static): strange closure type 1718511967
    (GHC version 7.10.3 for x86_64_unknown_linux)
    Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

the errors. Usually restarting stack works, but running stack in a loop and observing those issues, seems quite suboptimal.

[angerman]

Here's another one:

--  While building package vector-instances-3.3.1 using:
      ~/.stack/setup-exe-cache/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure (-6)
    Logs have been written to: ~/p/s/cd/.stack-work/logs/vector-instances-3.3.1.log

    Configuring vector-instances-3.3.1...
    Building vector-instances-3.3.1...
    Preprocessing library vector-instances-3.3.1...
    [1 of 1] Compiling Data.Vector.Instances ( src/Data/Vector/Instances.hs, .stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0/build/Data/Vector/Instances.o )
    ghc: internal error: evacuate(static): strange closure type 5
        (GHC version 7.10.3 for x86_64_unknown_linux)
        Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[angerman]

And yet another one. I just keep posting a few, so other might find this ticket, when looking for the message:

--  While building package hlibgit2-0.18.0.15 using:
      /tmp/stack1/hlibgit2-0.18.0.15/.stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure (-4)

[angerman]

    Configuring gitlib-3.1.1...
    setup-Simple-Cabal-1.22.5.0-ghc-7.10.3: The program 'ghc' version >=6.4 is
    required but the version of
    ~/.stack/programs/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/ghc-7.10.3/bin/ghc
    could not be determined.

[mgsloan]

Do you get such errors with our images? http://docs.haskellstack.org/en/stable/docker_integration/#image-repositories

Maybe it's an issue with how ghc is installed in the debian 8 image? Are you using stack setup?

[angerman]

This is the whole docker file:

FROM debian:8.3
MAINTAINER Moritz Angermann <moritz.angermann@gmail.com>
RUN apt-get update && apt-get install -y libgmp10 ca-certificates make gcc libgmp-dev libicu-dev libpcre3-dev libicu52 zlib1g-dev libpq-dev
# needed by pcre-light-0.4.0.4
RUN apt-get install -y pkg-config
# needed by hlibgit2
RUN apt-get install -y libssl-dev libcrypto++-dev
# needed by gitembed
RUN apt-get install -y git
# need xz for stack
RUN apt-get install -y xz-utils

ghc is installed using stack setup.

The weird thing is, it used to work a few days ago. What changes was
a) the stack version.
b) the lts version.

[angerman]

Here's another fun crash:

--  While building package base-orphans-0.5.3 using:
      ~/.stack/setup-exe-cache/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 127
    Logs have been written to: ~/p/s/cd/.stack-work/logs/base-orphans-0.5.3.log

    Configuring base-orphans-0.5.3...
    Building base-orphans-0.5.3...
    Preprocessing library base-orphans-0.5.3...
    [1 of 2] Compiling Data.Orphans.Prelude ( src/Data/Orphans/Prelude.hs, .stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0/build/Data/Orphans/Prelude.o )
    [2 of 2] Compiling Data.Orphans     ( src/Data/Orphans.hs, .stack-work/dist/x86_64-linux-dkf77007530c914a26f9fb968e255b5d7d/Cabal-1.22.5.0/build/Data/Orphans.o )
    Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 492: elf_machine_rela_relative: Assertion `((reloc->r_info) & 0xffffffff) == 8' failed!

[angerman]

@mgsloan as the issues look (to me at least) like memory or shared resource corruption, I tried again using a single cpu docker machine. While being sufficiently slower than the 4 core docker machine, the above mentioned issues did not show, and all 207 pkgs were compiled and installed properly.

Did the latest stack releases by any chance introduce additional parallelism?

[borsboom]

The only change in 1.0.4.3 relative to 1.0.4 is that your entire home
directory is mounted into the Docker container, instead of only the current
project and ~/.stack, but I have no idea why that would cause these
problems. No additional parallelism was introduced. I've been successfully
building with Docker (and multiple cores) using 1.0.4.3 since it was
released, but that's with the "official" fpco/stack-build images and its
derivatives. Have you tried Docker support with those images? In theory
what you're doing should work, but might be best to establish a baseline
with the official images first.

On Sat, Apr 23, 2016 at 2:21 AM Moritz Angermann notifications@github.com
wrote:

@mgsloan https://github.com/mgsloan as the issues look (to me at least)
like memory or shared resource corruption, I tried again using a single cpu
docker machine. While being sufficiently slower than the 4 core docker
machine, the above mentioned issues did not show, and all 207 pkgs were
compiled and installed properly.

Did the latest stack releases by any chance introduce additional
parallelism?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#2054 (comment)

[angerman]

I gave the fpco/stack-build image a try today, which resulted in a few crashes in-between stack build invocations on a four core virtual box:

--  While building package regex-tdfa-1.2.1 using:
      /Users/angerman/.stack/setup-exe-cache/x86_64-linux-dkda49f7ca9b244180d3cfb1987cbc9743/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux-dkda49f7ca9b244180d3cfb1987cbc9743/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure (-9) (THIS MAY INDICATE OUT OF MEMORY)

for different packages, but all were ExitFailure (-9)

Checking the produced vbox, it seems docker-machine builds by default virtual box images with 1GB or ram and 1cpu.

Using a four cpu, four gb ram vbox, does not crash.

[angerman]

Trying again with a 4gb/4core vbox and the debian image as above, does not prevent the crashes.

Could it be that the ghc that setup installes is somehow broken? What does the "patched" part with the fpco/stack-build mean?

[angerman]

If anyone has any suggestion how to properly debug this further, I'd give this a shot to figure out what's truly broken. I'm someone lost though.

[angerman]

Today I had a chance to try the docker for mac beta. Strangely it does not exhibit the crashes seen with the virtual box, docker-machine build for the debian image.

It does have a few other glitches, which make it break every few packages. Yet I can report, that stack does in principle work with the docker for mac beta.

[borsboom]

Docker integration is not supported on OS X. However, there are unsupported ways to make it work. In particular, see #194 (comment), which is still the approach that I use. Feel free to discuss in that issue. I do hope to implement full support once Docker for Mac is released to the public, but for now Docker for Mac is too unstable.

[creswick]

@borsboom I don't know if this is worth creating a new bug for, or the best place for this; maybe it's just useful to have here for future reference if it happens to someone else.

I'm also getting the ld failure:

Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 492: elf_machine_rela_relative: Assertion `((reloc->r_info) & 0xffffffff) == 8' failed!

but I'm not using docker. This is with VirtualBox, though (vagrant managed), running on OS X.

$ stack --version
Version 1.1.2, Git revision cebe10e845fed4420b6224d97dcabf20477bbd4b (3646 commits) x86_64 hpack-0.14.0

...and it's not 100% reproducible. If I can narrow it down I'll post reproduction details.