Crystal: Compiler spec failing on travis-ci because of insufficient memory

Created on 19 Oct 2018  路  10Comments  路  Source: crystal-lang/crystal

I noticed a lot of CI builds failing on travis-ci because they can't allocate enough memory at some point.

The failure is always fork: Cannot allocate memory (Errno) in spec Semantic: macro allows declaring class with macro expression (https://github.com/crystal-lang/crystal/blob/master/spec/compiler/semantic/macro_spec.cr#L569).

This really doesn't seem to make any sense. It doesn't always happen, but it comes up from time to time.

According to travis docs the machines running with Ubuntu Trusty on GCE have 7.5 GB of memory available. That should be plenty for compiling the std and compiler specs - even in one go.

bug infrastructure

Most helpful comment

Maybe we somehow blow up memory sharing? That is after a fork the OS lets the child use the parents memory until it tries to write to it, at that point it's copied. if we have a 2GB compiler process forking two times that's easily 6GB, if we fail to free unneeded memory after fork.

All 10 comments

If it always happens in that specific spec, we can change it or remove it. I don't see the need for invoking echo there. Plus, it won't work once we port the compiler to Windows.

But the intriguing question is: Why does it fail at this specific point? =) I can't see any indication for what might be a cause for this.

I think it's the only spec that compiles a program that executes a macro that ends up invoking a shell command. I don't know if that requires more memory for some reason or what...

Also, I think right now we are calling make crystal std_spec compiler_spec docs, and for example make std_spec will execute crystal spec/compiler_spec.cr which will compile that and start executing the specs while still having all the memory occupied because of the compile process. So maybe we should split that into crystal build spec/compiler_spec.cr && ./compiler_spec.

Maybe we somehow blow up memory sharing? That is after a fork the OS lets the child use the parents memory until it tries to write to it, at that point it's copied. if we have a 2GB compiler process forking two times that's easily 6GB, if we fail to free unneeded memory after fork.

@asterite the Makefile performs build and run in a different stages already $(O)/std_spec vs std_spec: $(O)/std_spec targets

Even in one step, it shouldn't fill 7,5 GB.

This occasionally happens on circle-ci as well which should have 8 GB RAM: https://circleci.com/gh/crystal-lang/crystal/16121

Can we close this now that #6968 #7263 merged?

6968 is probably completely unrelated. And #7263 only disables the very frequently failing 32-bit builds on travis.

This issue is about OOM failures in 64-bit builds on both travis and circle.

OOM failures keep coming even after #6962: https://circleci.com/gh/crystal-lang/crystal/20381

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lbguilherme picture lbguilherme  路  3Comments

jhass picture jhass  路  3Comments

oprypin picture oprypin  路  3Comments

oprypin picture oprypin  路  3Comments

costajob picture costajob  路  3Comments