Comment 1:

What does GODEBUG=allocfreetrace=1 say?

Comment 2:

Labels changed: added repo-main, release-go1.4.

Comment 3:

Looks like it is the allocations at fmt_test.go:872 for the Fprintf interface arguments
(7, 8, and 9).
fmt_test.go:872:    {0, `Fprintf(buf, "%x %x %x")`, func() { mallocBuf.Reset();
Fprintf(&mallocBuf, "%x %x %x", 7, 8, 9) }},
tracealloc(0xc20806d910, 0x10, int)
goroutine 5 [running]:
runtime.gomallocgc(0x10, 0x518000, 0x1, 0xc20806d908)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/runtime/malloc.go:317 +0x229 fp=0xc208037ce0 sp=0xc208037c48
runtime.newobject(0x518000, 0xc208037d98)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/runtime/malloc.go:348 +0x4a fp=0xc208037d08 sp=0xc208037ce0
runtime.convT2E(0x518000, 0xc208037d90, 0x0, 0x0)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/runtime/iface.go:141 +0xac fp=0xc208037d40 sp=0xc208037d08
fmt_test.func·007()
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/fmt/fmt_test.go:872 +0x130 fp=0xc208037e18 sp=0xc208037d40
testing.AllocsPerRun(0x64, 0x5c2158, 0x0)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/testing/allocs.go:33 +0xc0 fp=0xc208037e48 sp=0xc208037e18
fmt_test.TestCountMallocs(0xc20805c090)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/fmt/fmt_test.go:886 +0x271 fp=0xc208037f68 sp=0xc208037e48
testing.tRunner(0xc20805c090, 0x649440)
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/testing/testing.go:427 +0x8b fp=0xc208037f98 sp=0xc208037f68
runtime.goexit()
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/runtime/proc.c:1625 fp=0xc208037fa0 sp=0xc208037f98
created by testing.RunTests
        /usr/local/google/home/khr/sandbox/go-ro/src/pkg/testing/testing.go:509 +0x914
So maybe this test is just wrong after our interfaces-are-always-pointers conversion. 
Probably other such tests are only succeeding by chance.
There are 150 allocations for 100 iterations.  That's what I expect when allocating 3
8-byte items per iteration (tinyalloc is in play here, with one 16-byte alloc every
other call).

Comment 4:

I am curious why changing 100 to 1000 iterations or running the full suite fixes the
test?...

Comment 5:

This is the tinyalloc thing, right?
This is because tinyallocs don't increment runtime.Mallocs, and that's what
testing.AllocsPerRun uses.

Comment 6:

That's part of it, but not all of it.  Only every other allocation increments
runtime.Mallocs, so it measures 1.5 allocations per iteration.

Comment 7:

Filed issue #8734 to fix AllocsPerRun.

Comment 8:

all.bash runs tests with -short, and this test is skipped in -short, which is why the
build is ok.
Now that AllocsPerRun is fixed the test is accurate (exactly 200/300 allocs per 100
iterations), so the allowances just need to be increased. CL coming.

Comment 9:

This issue was closed by revision 73a82db.

Status changed to Fixed.