Repository navigation
Installing on Ubuntu with 512MB Ram Crashes #15
Description
When trying to run "go get honnef.co/go/js/dom" the process crashes with a "signal: killed" message.
Here is the output of "free -m" to show the memory available prior to install and then "go get honnef.co/go/js/dom":
root@recall:~# free -m
total used free shared buffers cached
Mem: 490 87 402 0 10 37
-/+ buffers/cache: 39 450
Swap: 0 0 0
root@recall:~# go get honnef.co/go/js/dom
go build honnef.co/go/js/dom: /usr/local/go/pkg/tool/linux_amd64/6g: signal: killedWhen looking up the "signal: killed" error related to 6g, a couple go bug reports say that "What causes the compiler to consume a lot of memory is large static initaliser blocks", eventually getting the process killed (https://code.google.com/p/go/issues/detail?id=6251).
Any way to get around this?
Thanks!
Activity
[-]Installing on Ubuntu with 512MB Ram Crashed[/-][+]Installing on Ubuntu with 512MB Ram Crashes[/+]dmitshur commentedon Feb 1, 2015
Since this package is meant to be compiled with the
jsarchitecture, building it withgodoes not make a lot of sense. If you don't provide-dflag togo get, it will get and build the package.So, it's likely what you want to do instead of
go get honnef.co/go/js/domis this:The
-dflag preventsgo getfrom building the package, stopping only after getting the source.The
-uflag instructsgo getto check for the latest version of the package and update if needed; you want to do that since older version of this package may have issues.See https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies for details.
This may or may not fix the root problem, but it's good orthogonal advice.
dominikh commentedon Feb 1, 2015
In our case, we don't run out of memory because of huge static initialisation, but because the Go compiler doesn't handle our big amount of types and interfaces and embedding of interfaces very well.
I only partially agree with @shurcooL's workaround. While that does allow to successfully download the package, the lack of actually compiling it also means that gocode will not provide completion, errcheck will take longer to run, and so on.
Unfortunately there's not really anything I can do about this, as ultimatively it's a problem with the Go compiler, not the package.
I'll leave the issue open to track any progress, but there won't be any immediate steps on my side.
fabioberger commentedon Feb 1, 2015
Ok sounds good, thanks for the response!