New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should this work? #947

Closed
cmoore opened this Issue Sep 8, 2015 · 18 comments

Comments

Projects
None yet
6 participants
@cmoore

cmoore commented Sep 8, 2015

Brand new stack install on Debian. No GHC installed.

This is using lts-3.4

$ mkdir stack && cd stack
$ stack unpack hlint
$ cd hlint-version
$ stack init
$ stack setup
$ stack install
haskell-src-exts-1.16.0.1: configure
haskell-src-exts-1.16.0.1: build
Progress: 1/4
--  While building package haskell-src-exts-1.16.0.1 using:
      /home/cmoore/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build --ghc-options -hpcdir .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/hpc/.hpc/ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure (-9)
    Logs have been written to: /home/cmoore/stack/hlint-1.9.21/.stack-work/logs/haskell-src-exts-1.16.0.1.log

    Configuring haskell-src-exts-1.16.0.1...
    Building haskell-src-exts-1.16.0.1...
    Preprocessing library haskell-src-exts-1.16.0.1...
    [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Language/Haskell/Exts/Annotated/Syntax.o )

    src/Language/Haskell/Exts/Annotated/Syntax.hs:112:1: Warning:
        The import of ‘Data.Foldable’ is redundant
          except perhaps to import instances from ‘Data.Foldable’
        To import instances alone, use: import Data.Foldable()

    src/Language/Haskell/Exts/Annotated/Syntax.hs:113:1: Warning:
        The import of ‘Data.Traversable’ is redundant
          except perhaps to import instances from ‘Data.Traversable’
        To import instances alone, use: import Data.Traversable()

On the one hand, I'm not sure how I could have done things differently, but on the other, haskell-src-exts is used, or at least used to be used, by quite a few packages, and I can't find any reference of people running into this problem.

Perhaps stackoverflow would have been a better place to post this. Apologies if so.

@cmoore

This comment has been minimized.

cmoore commented Sep 8, 2015

For what it's worth, stack install --resolver nightly-2015-09-07 gives the same error.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Sep 8, 2015

This isn't an issue with stack - the build for haskell-src-exts is running out of memory. See #859

@mgsloan mgsloan closed this Sep 8, 2015

@cmoore

This comment has been minimized.

cmoore commented Sep 8, 2015

Damnit, I was just a bit too slow to close this myself.

Sorry about this.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Sep 8, 2015

No problem! Thanks for reporting :)

Better to over-report than under-report. However, it is good to search around for existing issues / explanations first, though.

@radix

This comment has been minimized.

Contributor

radix commented Sep 8, 2015

Can stack detect when the child process died with -9 and print a helpful message about how compilation ran out of memory?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

No, since the child process is Cabal the library, not GHC. Cabal would need
to detect that and report I think

On Tue, Sep 8, 2015, 5:56 AM Christopher Armstrong notifications@github.com
wrote:

Can stack detect when the child process died with -9 and print a helpful
message about how compilation ran out of memory?


Reply to this email directly or view it on GitHub
#947 (comment)
.

@radix

This comment has been minimized.

Contributor

radix commented Sep 8, 2015

@snoyberg Okay, filed haskell/cabal#2813 - Thanks for the explanation.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

Looks good, thanks!

On Tue, Sep 8, 2015 at 7:01 AM, Christopher Armstrong <
notifications@github.com> wrote:

@snoyberg https://github.com/snoyberg Okay, filed haskell/cabal#2813
haskell/cabal#2813 - Thanks for the
explanation.


Reply to this email directly or view it on GitHub
#947 (comment)
.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 8, 2015

It looks to me like the Process exited with code: ExitFailure (-9) message is produced by stack itself, so I think we could capture it and make a more helpful message.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

How would this look? Just add a simple "ExitFailure (-9)" S.isInfixOf`` on every line that Cabal outputs and, if it matches, give an error message "maybe you ran out of memory?"

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 8, 2015

Is that necessary? The "ExitFailure (-9)" is produced by show exitCode in stack's code, so we should just be able to look at exitCode itself. Your idea would catch other cases where this would potentially happen, but so far the two cases I've seen (this issue and #859) are both where we have access to the ExitCode.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

Wow, you're right, I can't believe I didn't see that. OK, my mistake.

@snoyberg snoyberg reopened this Sep 8, 2015

@rvion

This comment has been minimized.

Contributor

rvion commented Sep 8, 2015

My 2 cents user feedback on that is that silent out-of-memory error are very frustrating.

I experienced this several time when compiling some projects on various remote low-end machines.

I am even used to start htop when compiling ghc code to monitor memory consumption 😞

@snoyberg snoyberg added this to the 0.3.0.0 milestone Sep 8, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

Actually, @mgsloan brought up something around auto-retrying a build due to memory exhaustion, and I made the same mistake of thinking we couldn't reliably detect it. Perhaps we should implement some logic along the lines of:

  • Do a first build
  • If the build fails due to signal 9:
    • Print a message "Out of memory when building foo, retrying by itself"
    • Grab a lock that will only acquire once no other builds are occurring, and prevent other builds from starting (likely a QSemN with a total of numjobs quantities)
    • Try to rebuild. If it fails due to signal 9 a second time, give a "you need more memory" error message
@radix

This comment has been minimized.

Contributor

radix commented Sep 8, 2015

FWIW, signal 9 is just SIGKILL, so it's not guaranteed that it's because of the OOM killer. It could be a user manually selecting the process and killing it with kill -9 or some sort of process manager.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

I should have noticed that... OK, I'm not convinced that what I described above is still a good idea, but it might be. After all, how common will it be that someone will kill -9 the GHC process instead of stack itself?

borsboom added a commit that referenced this issue Sep 8, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 8, 2015

As a starting point, I just pushed a change that switches the message to

Process exited with code: ExitFailure (-9) (THIS MAY INDICATE OUT OF MEMORY)

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 21, 2015

Since we can't count on ExitFailure -9 meaning anything in particular (could be OOM, could be a user-initiated kill -9) I don't think we can should do any automated retrying. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment