os: OpenBSD failure statting size of /dev/null

[bradfitz]

OpenBSD test failure (flake?) on a trybot run:

https://storage.googleapis.com/go-build-log/ea2b1f54/openbsd-amd64-gce58_25e3ccc7.log

--- FAIL: TestDevNullFile (0.00s)
    os_test.go:1551: wrong file size have 926960 want 0
FAIL
FAIL    os  0.373s

The code is just:

func TestDevNullFile(t *testing.T) {
        f, err := Open(DevNull)
        if err != nil {
                t.Fatalf("Open(%s): %v", DevNull, err)
        }
        defer f.Close()
        fi, err := f.Stat()
        if err != nil {
                t.Fatalf("Stat(%s): %v", DevNull, err)
        }
        name := filepath.Base(DevNull)
        if fi.Name() != name {
                t.Fatalf("wrong file name have %v want %v", fi.Name(), name)
        }
        if fi.Size() != 0 {
                t.Fatalf("wrong file size have %d want 0", fi.Size())
        }
}       

How can this be flaky?

/cc @randall77 @mdempsky

[bradfitz]

I can't reproduce with gomote and lots of iterations:

bradfitz@dev-bradfitz:~/go/src$ gomote run user-bradfitz-openbsd-amd64-gce58-0 go/bin/go test -run=TestDevNullFile -count=50000 os
ok      os      11.406s
bradfitz@dev-bradfitz:~/go/src$ gomote run user-bradfitz-openbsd-amd64-gce58-0 go/bin/go test -run=TestDevNullFile -count=50000 os
ok      os      9.920s

[mdempsky]

Brainstorming flake sources:

1. GC-related memory corruption? Because OpenBSD randomizes mmap more aggressively than other OSes, this has revealed issues in the GC before.
2. Within the kernel, I can only imagine maybe there's a problem with opening and closing multiple files at the same time, so maybe the FD table indexing gets mixed up and we end up fstat'ing a different open file by accident.

[bradfitz]

As long as we're brainstorming: maybe a liveness issue + the *os.File finalizer?

[bradfitz]

Re-running a stress test with:

$ gomote run -e GOGC=1 user-bradfitz-openbsd-amd64-gce58-0 go/bin/go test -short -count=50 os

[bradfitz]

No luck.

[rsc]

Can't reproduce and I assume we haven't seen this again. Let's wait until we do. It may be a bug in the Go OpenBSD support or a bug in OpenBSD or a bug in the core runtime (like the GC). I'd be more concerned if we saw this on a non-OpenBSD system. I don't think Go on OpenBSD is particularly stress-tested.