Comment 1:

TestFuzzRegressions test in encoding/gob is known to require lots of memory.

Comment 2:

I think the fuzz test should just be deleted. it causes more troubles than it addresses.

Comment 3:

I would like to leave it in. It's great for finding weird edge cases, and it has not
been problematic for ages. I think we should just disable it on low-memory systems, or
just make it use less RAM.

Comment 4:

But how do you tell whether to run it or not? I suggest instead we enable it only under
a flag that is off by default.

Comment 5:

A bunch of other tests have a
  if runtime.GOOS == "arm" { return }
at the top of them. That would be fine here too.

Comment 6:

I'm not convinced. It's possible this is just the 32-bit gc issue and that the same
things can happen on small-memory 32-bit systems.

Comment 7:

We could limit it to only 64-bit machines, then. It's still highly
valuable to have it there.

Comment 8:

FYI, only pkg/net/multicast_test.go skip a test on linux/ARM.

Comment 9:

Here is some debug about the gob oom error
raspberrypi(~/go/src/pkg/encoding/gob) % go test encoding/gob -v -test.run=Fuzz
runtime.sysmap: 1048576 bytes at fixed address 0x10700000
throw: runtime: out of memory - could not mmap fixed
exit status 2
FAIL    encoding/gob    0.011s

Comment 10:

This isn't an Arm problem, it affects pretty much any 32bit system. Running this on my
pandaboard the amount of RSS used for the Fuzz test varies wildly, most likely due to GC
conservatism.
pando(~/go/src/pkg/encoding/gob) % /usr/bin/time -v ./gob.test -test.run=Fuzz 2>&1 |
grep Maximum\ resident\ set
        Maximum resident set size (kbytes): 17200
pando(~/go/src/pkg/encoding/gob) % /usr/bin/time -v ./gob.test -test.run=Fuzz 2>&1 |
grep Maximum\ resident\ set
        Maximum resident set size (kbytes): 13520
pando(~/go/src/pkg/encoding/gob) % /usr/bin/time -v ./gob.test -test.run=Fuzz 2>&1 |
grep Maximum\ resident\ set
        Maximum resident set size (kbytes): 1058880
pando(~/go/src/pkg/encoding/gob) % /usr/bin/time -v ./gob.test -test.run=Fuzz 2>&1 |
grep Maximum\ resident\ set
        Maximum resident set size (kbytes): 10848
pando(~/go/src/pkg/encoding/gob) % /usr/bin/time -v ./gob.test -test.run=Fuzz 2>&1 |
grep Maximum\ resident\ set
        Maximum resident set size (kbytes): 1058848
It turns out this is another manifestation of issue #3225. Oddly the final comment by rsc
says that TestFuzz is disabled in -short mode, and this is still true. So there must be
another test that is triggering the same behaviour, possibly TestFuzzRegressions.

Labels changed: added arch-arm, os-linux.

Owner changed to @davecheney.

Status changed to Accepted.

Comment 11:

Digging in further (and adding a bit of swap), this fuzz regression test reliably needs
279mb of rss to run.
@dsymonds, is this expected, or does this sound like a problem ?
=== RUN TestFuzzRegressions
--- PASS: TestFuzzRegressions (0.11 seconds)
        codec_test.go:1469: seed=1328492090837718000 n=100 e=*float32
PASS
ok      encoding/gob    0.239s
        Command being timed: "go test -v -test.run=FuzzReg"
        User time (seconds): 20.28
        System time (seconds): 1.93
        Percent of CPU this job got: 87%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:25.37
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 279072
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 57929
        Voluntary context switches: 1181
        Involuntary context switches: 919
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

Comment 12:

I wouldn't be surprised by that. This is throwing random data at gob,
and some forms are going to trigger large allocations. The trick is to
make the gob package not allocate stupid amounts and cleanly reject
extreme inputs, which could form a DoS vector. So, yes, it sounds like
the test is doing an adequate job.

Comment 13:

Maybe we should tell the Pi folks they should attach some kind of swap device if they
want to compile from source. Swap is pretty much mandatory to get through the gc test
portion of the build.

Comment 14:

That seems reasonable to me. Or just tell them that they won't be able
to run 100% of the tests without it.

Comment 15:

I'd prefer to disable the fuzz test unless explicitly requested.

Comment 16:

This issue was closed by revision bbe6017.

Status changed to Fixed.