Skip to content

"os/exec": problem building with -race in MacOS Monterey 12.1 when using package "os/exec" #50172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jeberly opened this issue Dec 14, 2021 · 1 comment

Comments

@jeberly
Copy link

jeberly commented Dec 14, 2021

What version of Go are you using (go version)?

go version go1.17.5 darwin/amd64

Does this issue reproduce with the latest release?

I am using latest

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOVERSION="go1.17.5"

Important, I hit this issue on upgrading to MacOS Monterey, specifically 12.1 (21C52)


MacOS Monterey, specifically 12.1 (21C52)

What did you do?

After building with -race, it fails to run. Here is a small sample go program that reproduces the issue.

package main

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

func main() {
	path, err := exec.LookPath("uname")
	if err != nil {
		panic(err)
	}

	cmd := exec.Command(path, "-a")
	var out bytes.Buffer
	cmd.Stderr = nil // goes to os.DevNull
	cmd.Stdout = &out
	err = cmd.Run()
	if err != nil {
		panic(err)
	}

	fmt.Println(out.String())
}

What did you expect to see?

The binary would run without errors.

What did you see instead?

➜  hello ./hello         
hello(8085,0x79c0600) malloc: *** error for object 0x600001700080: pointer being freed was not allocated
hello(8085,0x79c0600) malloc: *** set a breakpoint in malloc_error_break to debug
SIGABRT: abort
PC=0x7ff81d7f7112 m=0 sigcode=0

goroutine 0 [idle]:
syscall.rawSyscall(0x10d11a0, 0x0, 0x0, 0x0)
	/usr/local/go/src/runtime/sys_darwin.go:77 +0x47 fp=0xc000121888 sp=0xc000121868 pc=0x109db67
syscall.rawSyscall(0x10a37e5, 0x0, 0x0, 0x1)
	<autogenerated>:1 +0x26 fp=0xc0001218d0 sp=0xc000121888 pc=0x10a3e46
syscall.forkAndExecInChild(0xc00013c098, {0xc000130030, 0x3, 0x1}, {0xc0001402c0, 0x2c, 0x0}, 0x0, 0x0, 0xc000121bd8, ...)
	/usr/local/go/src/syscall/exec_libc2.go:80 +0xed fp=0xc000121960 sp=0xc0001218d0 pc=0x10cd3ad
syscall.forkExec({0xc00013c059, 0x7}, {0xc000148000, 0x2, 0x2}, 0xc000121bd8)
	/usr/local/go/src/syscall/exec_unix.go:210 +0x58f fp=0xc000121af8 sp=0xc000121960 pc=0x10ce42f
syscall.StartProcess(...)
	/usr/local/go/src/syscall/exec_unix.go:256
os.startProcess({0xc00013c059, 0x7}, {0xc000148000, 0x2, 0x2}, 0xc000121e68)
	/usr/local/go/src/os/exec_posix.go:55 +0x526 fp=0xc000121c30 sp=0xc000121af8 pc=0x10e3e06
os.StartProcess({0xc00013c059, 0x7}, {0xc000148000, 0x2, 0x2}, 0x55555555555555)
	/usr/local/go/src/os/exec.go:109 +0x7a fp=0xc000121c90 sp=0xc000121c30 pc=0x10e37da
os/exec.(*Cmd).Start(0xc000140160)
	/usr/local/go/src/os/exec/exec.go:422 +0x9d4 fp=0xc000121ec0 sp=0xc000121c90 pc=0x10fb614
os/exec.(*Cmd).Run(0xc00013c059)
	/usr/local/go/src/os/exec/exec.go:338 +0x31 fp=0xc000121f00 sp=0xc000121ec0 pc=0x10fabd1
main.main()
	/Users/john/go/src/github.com/john/hello/main.go:19 +0x150 fp=0xc000121f80 sp=0xc000121f00 pc=0x10fd530
runtime.main()
	/usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc000121fe0 sp=0xc000121f80 pc=0x1073c87
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc000121fe8 sp=0xc000121fe0 pc=0x10a0d41
@cherrymui
Copy link
Member

Looks like a dup of #50073 . It should be fixed at Go tip or Go 1.18beta1, and will be included in the next 1.17 minor release. Thanks.

@golang golang locked and limited conversation to collaborators Dec 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants