@ayanamist would you mind posting a full/complete program, say in a playground snippet that can
be re-runnable by anyone?
Currently your code snippet doesn't match up with the execution lines in the crash report,
so it is hard to traceback to what tripped out.
Thanks.

@odeke-em I have modified the description to add pointed line number in the line comment.
The full program is very complicated, but above provided code has been running for months without panic and i don't use any unsafe package methods and any third party package.
The original program restarts after panic and running well now, and at the same time it runs the same code provided above every 5 minutes on other thousands machines.
I think it maybe related with some race conditions?

@davecheney I add -race after found this issue, but runs for hour but got nothing.
I think the race condition occurs in runtime but not my program, because the code provided shows that, after constructing a os.Command object, i call Start immediately within the same method.

@davecheney I mentioned above that i got nothing after enabled -race. I suspect race occurs in runtime because i don't use unsafe to manipulate anything and i don't use any third party library, and the exec.Command object does not escape out of the same method.

@davecheney So i have no idea why it panics on runtime.SetFinalizer

Is your source code available? Can you please provide a runnable code sample that will let others try to reproduce and debug the issue.

@davecheney Sorry but source code is not available, and even i attach it, i think it won't reproduce. The same code has been running for months on thousands machines, and even it panics this morning, after restart it runs well until now.

For questions about Go, see https://golang.org/wiki/Questions.

@bradfitz Why this issue closed? I'm reporting a panic happening in runtime.SetFinalizer but not consulting for any golang usage.

@ayanamist unfortunately your report as is isn't self contained/reproducible.
@davecheney and I have both asked for a complete program in our comments. Currently with the above content, it looks like more like a question for the Go help sites than a bug report with actionable items for contributors to look at.

Perhaps to help move up its status, here are some points that might be useful:

1. What is "some-command"?
2. stdout in your snippet is created but not used, anything related to that?
3. Here is a sample complete snippet as the template encourages https://play.golang.org/p/JnGVQ8Xyr3 or

package main

import (
	"fmt"
	"io/ioutil"
	"os/exec"
)

func execIt() error {
	cmd := exec.Command("echo")
	cmd.Stderr = ioutil.Discard
	if _, err := cmd.StdoutPipe(); err != nil {
		return err
	}
	if err := cmd.Start(); err != nil {
		if cmd.Process != nil {
			cmd.Process.Kill()
		}
		return err
	}
	return cmd.Wait()
}

func main() {
	fmt.Printf("err: %v\n", execIt())
}

hope that looks similar to what you are doing
4) What is the nature of the code being ran? How heavily is the code used? I see your stack trace points to the use of SetFinalizer which for go1.7.5 is at https://github.com/golang/go/blob/release-branch.go1.7/src/runtime/mfinal.go#L303. Maybe that might help.

1. some-command is not part of my code, and i think it will not interfere with my program memory.
2. 3. More codes here

func func3() (boolean, error) {
	foundSomething := false
	cmd := exec.Command("echo", "foobar")
	cmd.Stderr = ioutil.Discard
	stdout, err := cmd.StdoutPipe()
	if err != nil {
		return foundSomething, err
	}
	if err := cmd.Start(); err != nil {  // main.go:186
		if cmd.Process != nil {
			cmd.Process.Kill()
		}
		return foundSomething, err
	}
	go func() {
		time.Sleep(5 * time.Second)
		cmd.Process.Kill()
	}()
	scanner := bufio.NewScanner(stdout)
	for scanner.Scan() {
		line := scanner.Text()
		i := strings.Index(line, ":")
		if i < 0 {
			continue
		}
		if strings.Contains(line, "foo") {
			foundSomething = true
		}
	}
	err = cmd.Wait()
	return foundSomething, err
}

4. Every 5 minutes run this code in a single goroutine, and runtime.SetFinalizer is used directly by os.exec package but not my code.

I'm sorry, I don't entirely understand what you are saying. Did this crash happen more than once?

The crash reported in the original comment is during the call to clear the finalizer when closing a file descriptor. It's not a race condition. The only thing I can think of that could cause this crash is some sort of memory corruption.

@ianlancetaylor So far, it only happens once. Do you mean other program cause my program memory corruption?

I don't think a different program could cause memory corruption, but it is possible that there was a hardware failure on your machine.

I'll investigate whether there is a hardware problem, thank you.