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

os: TestGetppid fails on plan9 #8206

alexbrainman opened this issue Jun 14, 2014 · 7 comments

os: TestGetppid fails on plan9 #8206

alexbrainman opened this issue Jun 14, 2014 · 7 comments


Copy link

@alexbrainman alexbrainman commented Jun 14, 2014

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

Copy link

@gopherbot 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).

Copy link

@0intro 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
ok      os  0.034s
term% go run getppid.go

Copy link

@ality 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.

Copy link

@gopherbot 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"
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.

Copy link

@ality ality commented Jun 14, 2014

Comment 6:

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
Copy link

@gopherbot gopherbot commented Apr 18, 2016

CL mentions this issue.

@0intro 0intro reopened this May 10, 2016
Copy link

@0intro 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    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.

@rsc rsc unassigned 0intro Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants