Should this work?

[cmoore]

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]

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

[mgsloan]

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

[cmoore]

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

Sorry about this.

[mgsloan]

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]

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

[snoyberg]

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]

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

[snoyberg]

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]

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]

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]

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]

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

[rvion]

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]

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]

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]

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]

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]

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.