Comment 1 by divoxx:

I can't reproduce on my MBP as well... do we known the model or version of OSX of the
env that this happens?

Comment 2:

all we know is that the builder runs OS X 10.7 on 2011 Mac Mini, 2.4Ghz Core i5.
(see https://code.google.com/p/go-wiki/wiki/DashboardBuilders)
because they are run by dave, perhaps we can ask him to provide more details.

Comment 3:

Yup, mac mini running Lion 10.7.5.
odessa(~) % uname -a
Darwin odessa.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012;
root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

Comment 4:

Can't reproduce it on MacBook Air 10.8.2 as well. Run 1000+ times.

Comment 5:

I looked at the test, trying to eyeball the flakiness, but it seems fine.
The parent host process has just started reading 1 MB from the child process.  The child
must have been there if the headers were all read correctly, and the child shouldn't
already be gone, since it has 1 MB of data to write.  It's not possible that on older OS
X, the pipe has a buffer size >= 1 MB, is it?
The other possibility is that isProcessRunning (signals?) is unreliable on old OS X:
from posix_test.go:
func isProcessRunning(t *testing.T, pid int) bool {
    p, err := os.FindProcess(pid)
    if err != nil {
        return false
    }
        return p.Signal(syscall.Signal(0)) == nil
}

Comment 6:

OS X uses some tricks to expand the pipe buffers if it decides that doing
so would make programs would run faster, up to a true maximum of 16 MB. The
exact code seems to change from version to version, but the 10.7.5 kernel
that Dave reported does include this code. Perhaps running the builder in a
loop was enough to make the kernel think this was a worthwhile
optimization. :-)

Comment 7:

Crazy. Sent out https://golang.org/cl/7453049

Comment 8:

This issue was closed by revision 7903e36.

Status changed to Fixed.