$ go version
go version devel +9ef5ee911c Tue Aug 7 14:36:14 2018 +0000 linux/amd64
$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7671        2308        3929         939        1433        4185
$  go test net
signal: killed
FAIL    net     9.743s

If I do go test -v net, I can see:

[...]
=== RUN   TestTCPSelfConnect
fatal error: runtime: out of memory
[...]

I presume that TestSplice/big is the culprit, as it seems to be the test that allocates the most memory by far. I realise that it's the purpose of the test, but I still think this test shouldn't fail if one doesn't have enough memory available.

I realise that in this scenario I only have about 4GB of available memory, but that still seems to me like it should be plenty to be able to run go test std. In fact, I encountered this crash while running that command with about 6GB of available memory (to reproduce with just go test net, I started using more memory to save time).

I wonder what would be the best way to keep the test working as it is on systems with more memory, while keeping it from crashing the runtime on systems with less memory. Even if we had a way to check the available memory at the start of the test, that still isn't a guarantee that we won't crash the runtime.

There's always the option of saying "at least 8GB of available memory is required to run go test std". But hopefully that required minimum would be much lower - 8GB of physical memory is still common, even in fairly new laptops out there.