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

os: TestGetppid fails on plan9 #8206

Open
alexbrainman opened this Issue Jun 14, 2014 · 7 comments

Comments

Projects
None yet
5 participants
@alexbrainman
Member

alexbrainman commented Jun 14, 2014

--- FAIL: TestGetppid (0.02 seconds)
    os_test.go:1318: Child process reports parent process id '0', expected '917122'

Alex
@gopherbot

This comment has been minimized.

gopherbot commented Jun 14, 2014

Comment 1 by lucio.dere:

Curiously, the C routine for getpid() in runtime/os_plan9.c checks for both leading
spaces and tabs, whereas the Go version in syscall/syscall_plan9.go restricts itself to
checking the contents of #c/pid for leading spaces.
Looking at the code for getppid() in syscall/sycall_plan9.go, I cannot see any other
distinctive features (there is no room for them) that could explain why one syscall
succeeds and the other fails.
That basically says: either tabs are important or the absence of getppid() in
runtime/os_plan9.c is significant (but the latter is really unlikely).
Lucio.
@0intro

This comment has been minimized.

Member

0intro commented Jun 14, 2014

Comment 2:

It seems Getppid() always return 0 on Plan 9 in this test.
This is rather surprising, since writing a simple program calling
os.Getppid works as expected.
term% GO_WANT_HELPER_PROCESS=1 go test -run TestGetppid
0
ok      os  0.034s
http://play.golang.org/p/npUUya7FmI
term% go run getppid.go
7137
@ality

This comment has been minimized.

Member

ality commented Jun 14, 2014

Comment 3:

This is an artifact of the way we fork runtime procs.
RFNOWAIT disassociates the child from the parent so
if the current goroutine is running on a proc that isn't
the initial runtime proc, reads from #c/ppid will always
return 0.
Since the runtime doesn't use threads on Plan 9, we need
to decide precisely what the semantics of os.Getpid and
os.Getppid should be for user code.
Thoughts?
@gopherbot

This comment has been minimized.

gopherbot commented Jun 14, 2014

Comment 4 by lucio.dere:

For the purposes of this test, the result of invoking geppid have to match what the
Unixes deliver.  If this isn't implicit for Plan 9, then the problem has already been
resolved by removing the test.
Of course, only until some application assumes a working os.Getppid() and the Plan 9
implementation gets bitten (we have an outstanding issue in this vein that Gustavo
Niemeyer promised to look at: "undefined: syscall.WaitStatus" when trying his new "pipe"
package).
It seems to me that either we ensure that the PID syscalls are consistent with Unix
(Posix?) expectations across their semantic effect, or we declare Plan 9 anomalous and
make sure this is carefully and clearly documented so that we don't get caught again.
Lastly, maybe I missed a suggestion that we put on a thinking cap and figure what
combination of flags will produce Unix-y behaviour for getpid and getppid; I can't think
that anyone will know this better than Rob and Russ.
Lucio.
@ality

This comment has been minimized.

Member

ality commented Jun 14, 2014

Comment 6:

Lucio,
The syscall package is os-dependent: there is no guarantee that
the API is the same for all supported operating systems. I sent
a CL years ago—one that I'd like to eventually revise—with the
intention of completely stripping out all the Unix compatibility
stuff from the Plan 9 syscall package. It was put there early in
the life of the port only for expediency and should be removed.
This is unrelated to the issue at hand, though, so if you want
to discuss it more we should probably move to the mailing list.

@rsc rsc removed the os-plan9 label Apr 10, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@0intro 0intro self-assigned this Jul 30, 2015

@gopherbot

This comment has been minimized.

gopherbot commented Apr 18, 2016

CL https://golang.org/cl/22164 mentions this issue.

@gopherbot gopherbot closed this in a677724 May 10, 2016

@0intro 0intro reopened this May 10, 2016

@0intro

This comment has been minimized.

Member

0intro commented May 11, 2016

This issue is still current, despite TestGetppid apparently passing on fast machines,
like the plan9/386 builder.

This is failing on the plan9/arm builder:

--- FAIL: TestGetppid (0.12s)
    os_test.go:1727: Child process reports parent process id '178449', expected '178447'
FAIL
FAIL    os  11.413s

It fails on the plan9/arm builder because it's slow enough that the parent goroutine get
rescheduled to another process, after forking the child.

The same behavior can be reproduced on x86, by adding a sleep before calling Getppid
in the child process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment