Installing on Ubuntu with 512MB Ram Crashes

[fabioberger]

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: killed

When 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!

[dmitshur]

Since this package is meant to be compiled with the js architecture, building it with go does not make a lot of sense. If you don't provide -d flag to go 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/dom is this:

go get -d -u honnef.co/go/js/dom

The -d flag prevents go get from building the package, stopping only after getting the source.

The -u flag instructs go get to 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]

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]

Ok sounds good, thanks for the response!