go: x/tools/go/internal/gcimporter: frequent failures without useful output

@findleyr You are correct. I didn’t have the latest. Now if I try on various systems I have access to, I am not able to reproduce a failure with this test, even when using the same configuration as the build machines.

We can keep trying, but IMO this should not be a release blocker: the overlap between “too infrequent to debug” and “frequent enough to be a release blocker” should be empty.

I agree with that assessment. I think 7 failures per month is still too high long-term, but it’s far lower than the failure rate in May. I think it’s good enough not to be a release-blocker at this point.

Note that the openbsd failures are actually tracked separately by #36563, and the scaleway failures went away when the scaleway machines were removed in #45066.

So, filtering those out as well yields the following recent failures:

I.e. 7 in the last month. In our recent attempts to debug this, we’ve been unsuccessful at reproducing it with either slowbots or gomote. We can keep trying, but IMO this should not be a release blocker: the overlap between “too infrequent to debug” and “frequent enough to be a release blocker” should be empty. I think if we want to achieve a lower level of flakiness on the builders, we need to first make it easier to identify and diagnose flakes.

@bcmills, @stamblerre, @golang/release please let me know if you feel differently. I’d like to wait for consensus before removing the release-blocker label.

It may also be worthwhile to brainstorm about what tooling could make this easier. I have some ideas, but don’t want to distract the conversation from deciding whether this should be a release blocker.

I’m not sure if this is OOM-related. In local testing, I always get non-empty output for that, even when the process is terminated by the kernel instead of the runtime:

example.com$ go test ./oom
signal: killed
FAIL    example.com/oom 71.700s
FAIL

-- go.mod --
module example.com

go 1.14
-- oom/oom_test.go --
package oom_test

import (
        "math/rand"
        "runtime"
        "testing"
)

func TestOutOfMemory(t *testing.T) {
        var stuff [][]byte
        for {
                next := make([]byte, 1<<30)
                for i := 0; i < len(stuff); i += 4 << 10 {
                        next[i] = byte(rand.Int())
                }
                stuff = append(stuff, next)
        }
        runtime.KeepAlive(stuff)
}

Is it possible that the test is somehow invoking os.Exit itself with a nonzero exit code?