I'll give it a shot if this issue is not already taken.

The Run call is racing with the shutdown of the test. I'm not sure how much we actually care about this data race - in practice you are not going to have your program exit as you're in the midst of attempting to start a child process.

@Dhananjay92 You're welcome to investigate trying to fix this.

I don't see any locking/synchronization in exec.go or file_unix.go. Perhaps, it is by design that users should prevent such data races by avoiding (*File).Close() while cmd.Run() is in progress.

The Run call is racing with the shutdown of the test. I'm not sure how much we actually care about this data race - in practice you are not going to have your program exit as you're in the midst of attempting to start a child process.

FWIW, the same race detector report is printed when a time.Sleep(1 * time.Second) is added like so:

package example_test

import (
    "fmt"
    "os"
    "os/exec"
    "time"
)

func ExampleFoo() {
    fmt.Println("foo")

    cmd := exec.Command("/bin/sh", "-c", "sleep 999d")
    cmd.Stdout = os.Stdout
    go cmd.Run()

    time.Sleep(1 * time.Second)

    // OUTPUT:
    // foo
}

I don’t 100% understand why the race detector is flagging this, but in the real-life situtation in which I encountered this issue, I don’t think a child process was being started while the test was exiting. Rather, that child process was already running.

The race detector doesn't care about sleeps. It cares about reads and writes of the same memory location with no happens-before relationship (see https://golang.org/ref/mem).

This is a race between the close of os.Stdout in runExample, which sets os.Stdout.fd = -1, and the read of os.Stdout.fd (because os.Stdout is in sysattr.Files) in startProcess.

As far as I can tell this is a real race. The code in package example is going to close stdout. At the same time, the goroutine is getting stdout's file descriptor to pass it to the child process. There is no synchronization between those two steps, and even if something were added it would still be a race whether the child process got an open file descriptor or not. So, closing.

Thanks for looking into this.

I don’t entirely understand what closing this issue implies. Are you saying that one must not use os.Stdout in example code?

It's fine to use os.Stdout in example code. What is not fine is using os/exec to start a process running in a separate goroutine, where the stdout of that process is set to os.Stdout, and to then use os.Stdout in any way before waiting for the process to complete, including putting using an example with a // OUTPUT comment.

Basically, don't write

cmd.Stdout = os.Stdout
go cmd.Run()

in an example with a // OUTPUT comment. I don't actually see how that is a meaningful thing to do anyhow. If you aren't waiting for the process to complete, how can you know what the output is? If you don't care what the output is, why are you setting cmd.Stdout?

Thanks for clarifying.

In the scenario where this issue was filed from, a library external to my code was creating a subprocess with cmd.Stdout = os.Stdout.

IIUC, the data race happens if and only if processes are not terminated correctly. I’ll take this up with the authors of said library, possibly there’s a bug related to context cancellation here.