runtime: Go runtime in DLL marks stdin/out/err not inherited on Windows #24328
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
Milestone
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.10 windows/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?GOARCH=amd64
GOHOSTARCH=amd64
GOHOSTOS=windows
GOOS=windows
What did you do?
Source file godll.go
Command to build godll.dll from source file godll.go
go build -buildmode=c-shared -o godll.dll
Python source file loadgo.py
Command Prompt Window commands and output
Note that these commands are executed interactively with an interactive Python interpreter.
What did you expect to see?
The Python function executes the help(print) command before and after loading the godll.dll and calling its exported function goFunc.
I expected to see the help(print) command output both before and after the printed line "goFunc called".
What did you see instead?
I only see the help(print) command output before the printed line "goFunc called".
The Python help command output is broken after the Go runtime is loaded into the Python interpreter process.
The Python help command works by storing the help command output in a temporary text file and then spawning the "more" command to read from the temporary text file.
The Python interpreter expects that the stdout file handle will be inherited by the spawned "more" command.
When a DLL built with Go is dynamically linked-to in a process, then during the Go runtime initialization, the Go runtime sets "CloseOnExec" behavior for the stdin, stdout, and stderr handles.
That behavior is due to the following code in C:\go\src\syscall\syscall_windows.go
If I comment out this line of code in the Go runtime:
//CloseOnExec(r)
Then the Go runtime no longer breaks the Python help command, and the output from the second help command is visible after the line "goFunc called".
In my opinion, when the Go runtime is within a DLL, the Go runtime should not call CloseOnExec for the std handles. A DLL is a guest within the process and a DLL should not assume that it owns or controls the std handles.
This behavior of the Go runtime within a Windows DLL is an impediment to creating DLLs in Go that can be used by Python.
My current workaround is to comment out the problematic line of code in the Go runtime, but there are obvious drawbacks to that workaround.
The text was updated successfully, but these errors were encountered: