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.
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?
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
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.