Skip to content
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

Jump to bottom

os/exec: undocumented breaking change in exec.Command behavior on Windows between Go versions 1.16.8 and 1.17.1 #48393

Open
mbushkov opened this issue Sep 14, 2021 · 8 comments
Open

os/exec: undocumented breaking change in exec.Command behavior on Windows between Go versions 1.16.8 and 1.17.1 #48393

mbushkov opened this issue Sep 14, 2021 · 8 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone
Go1.17.2

Comments

@mbushkov
Copy link

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

$ go version
go version go1.17.1 windows/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env
go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\mbushkov\AppData\Local\go-build
set GOENV=C:\Users\mbushkov\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\mbushkov\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\mbushkov\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17.1
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\mbushkov\AppData\Local\Temp\2\go-build3022852068=/tmp/go-build -gno-record-gcc-switches

What did you do?

On Windows, when using exec.Command and relying on inheriting handles and using inherited handles in the child process, code that worked when compiled Go 1.16.8 no longer works when compiled with Go 1.17.1.

The culprit seems to be the AdditionalInheritedHandles attribute introduced in the context of #44011, and particularly the following breaking change: 2d76081#diff-ec673c10a75fe2d2faa9c788e03823294b263c68cc3de50f4a0865a53e28f3a3R340. In Go 1.16, on Windows, child processes inherit all handles marked as inherited. In Go 1.17 the handles to be inherited have to be explicitly added to the AdditionalInheritedHandles list.

Sample program:

package main

import (
	"fmt"
	"log"
	"os"
	"os/exec"
	"strconv"
	"strings"
	"syscall"
)

func main() {
	var in_handle *os.File = nil

	for _, e := range os.Environ() {
		pair := strings.SplitN(e, "=", 2)
		if pair[0] == "INHERITED_FD" {
			fd, err := strconv.Atoi(pair[1])
			if err != nil {
				log.Fatalf("Can't parse INHERITED_FD")
			}
			in_handle = os.NewFile(uintptr(fd), "file")
		}
	}

	if in_handle == nil {
		self_exe := os.Args[0]
		fmt.Printf("Haven't seen INHERITED_FD: assuming being a parent process, starting child with %s\n", self_exe)

		pr, pw, err := os.Pipe()
		if err != nil {
			log.Fatalf("Can't create pipe")
		}

		cmd := exec.Command(self_exe)

		fd := pr.Fd()
		syscall.SetHandleInformation(syscall.Handle(fd), syscall.HANDLE_FLAG_INHERIT, 1)
		cmd.SysProcAttr = &syscall.SysProcAttr{}
		// NOTE: The code fails without this line on 17.1:
		// cmd.SysProcAttr.AdditionalInheritedHandles = append(cmd.SysProcAttr.AdditionalInheritedHandles, syscall.Handle(fd))

		cmd.Env = append(os.Environ(), fmt.Sprintf("%s=%d", "INHERITED_FD", fd))

		cmd.Stdout = os.Stdout
		cmd.Stderr = os.Stderr
		if err := cmd.Start(); err != nil {
			log.Fatalf("Couldn't start: %v", err)
		}

		n, err := pw.Write([]byte("blah"))
		if err != nil {
			log.Fatalf("Couldn't write to pipe")
		}
		fmt.Printf("Written %d bytes\n", n)
		pw.Close()

		if err := cmd.Wait(); err != nil {
			log.Fatalf("Waiting for process failed: %v", err)
		}
	} else {
		fmt.Printf("Found INHERITED_FD (%v), assuming being a child process\n", in_handle.Fd())
		data := make([]byte, 4)
		n, err := in_handle.Read(data)
		if err != nil {
			log.Fatalf("Can't read data from inherited fd")
		}
		fmt.Printf("Read %d bytes: %v\n", n, string(data))
	}
}

Running this on different versions of Go produces different results:

$ go1.16.8 build inherited_attrs.go

$ inherited_attrs.exe
Haven't seen INHERITED_FD: assuming being a parent process, starting child with inherited_attrs.exe
Written 4 bytes
Found INHERITED_FD (312), assuming being a child process
Read 4 bytes: blah

$ go1.17.1 build inherited_attrs.go

$ inherited_attrs.exe
Haven't seen INHERITED_FD: assuming being a parent process, starting child with inherited_attrs.exe
Written 4 bytes
Found INHERITED_FD (320), assuming being a child process
2021/09/14 22:03:08 Can't read data from inherited fd
2021/09/14 22:03:08 Waiting for process failed: exit status 1

What did you expect to see?

I expected one of the following:

  • Either that the output of the code compiled with Go 1.16.8 and Go 1.17.1 to be the same
  • Or that the breaking change in exec.Command's behavior on Windows to be clearly marked as such in release notes.

What did you see instead?

Same code compiled with Go 1.16.8 and Go 1.17.1 exhibits different behavior.

The underlying breaking change in Go's behavior is not clearly marked as such in Go 1.17 release notes. The current document states:

The Windows version of SysProcAttr has two new fields. AdditionalInheritedHandles is a list of additional handles to be inherited by the new child process. ParentProcess permits specifying the parent process of the new process.

This is misleading and seems to actually be incorrect, as only the handles list in AdditionalInheritedHandles are going to be inherited by the new child process.
@ALTree ALTree added OS-Windows NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 14, 2021
@ALTree ALTree changed the title Undocumented breaking change in exec.Command behavior on Windows between Go versions 1.16.8 and 1.17.1 os/exec: undocumented breaking change in exec.Command behavior on Windows between Go versions 1.16.8 and 1.17.1 Sep 14, 2021
@ALTree ALTree added this to the Go1.18 milestone Sep 14, 2021
@cespare
Copy link
Contributor

cespare commented Sep 14, 2021

/cc @zx2c4 @alexbrainman

@bcmills
Copy link
Contributor

bcmills commented Sep 15, 2021 •
edited

Is this a duplicate of (or related to) #48040?

@zx2c4
Copy link
Contributor

zx2c4 commented Sep 16, 2021

I can submit a patch to make the release notes more clear, I guess?

@gopherbot
Copy link

Change https://golang.org/cl/350412 mentions this issue: [release-branch.go1.17] doc/go1.17: clarify AdditionalInheritedHandles behavior

@mknyszek mknyszek modified the milestones: Go1.18, Go1.17.4 Nov 12, 2021
@mknyszek
Copy link
Contributor

I get this impression that this shouldn't be in the 1.18 milestone. Maybe the next 1.17 milestone? (We're currently trying to clear out 1.18 now that we've entered the freeze.)

@bcmills
Copy link
Contributor

bcmills commented Nov 12, 2021

I think this was fixed by CL 350416.

@bcmills bcmills closed this as completed Nov 12, 2021
@mknyszek mknyszek modified the milestones: Go1.17.4, Go1.17.2 Dec 2, 2021
@brianryner8
Copy link

I think the original issue reported here has not been fixed. The release notes still only say: "AdditionalInheritedHandles is a list of additional handles to be inherited by the new child process." The issue being reported here is that prior to go 1.17, all inheritable file handles would be inherited (if NoInheritHandles is false), whereas in 1.17 only stdin/out/err and the handles listed in AdditionalInheritedHandles are inherited. This behavior change is not mentioned anywhere in the release notes.

(It also makes it much harder for our go binary that wants to transparently pass all inheritable handles through to the subprocess; I can file a separate issue about that if you'd prefer).

@alexbrainman
Copy link
Member

I think the original issue reported here has not been fixed. ... This behavior change is not mentioned anywhere in the release notes.

Agree. The release notes did not get updated. Jason started https://golang.org/cl/350412 but abandoned it.

@brianryner8 would you like to change the docs yourself? Here is how to contribute https://go.dev/doc/contribute

@bcmills I will reopen this issue. Feel free to close it if you disagree and think the doco is good enough.

(It also makes it much harder for our go binary that wants to transparently pass all inheritable handles through to the subprocess; I can file a separate issue about that if you'd prefer).

I don't think you want every inheritable handle of your parent process to silently be inherited by every child. This will make a lot of unexplained bugs, like "unclosed handles". But please file a new issue, if you still have any bug or suggestion to discuss.

Thank you.

Alex

@alexbrainman alexbrainman reopened this Jul 1, 2022
@brianryner8 brianryner8 mentioned this issue Jul 1, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Milestone
Go1.17.2
Development

No branches or pull requests
9 participants
@zx2c4 @cespare @mbushkov @mknyszek @ALTree @bcmills @gopherbot @alexbrainman @brianryner8