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 😞