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: TestStdPipe flake on darwin #15613

Closed
bradfitz opened this issue May 9, 2016 · 4 comments
Closed

os: TestStdPipe flake on darwin #15613

bradfitz opened this issue May 9, 2016 · 4 comments
Labels
FrozenDueToAge Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented May 9, 2016

Noticed on a trybot run:

https://storage.googleapis.com/go-build-log/0e1049fe/darwin-amd64-10_10_bc2daf40.log

--- FAIL: TestStdPipe (0.08s)
    pipe_test.go:85: unexpected exit status exit status 2 for descriptor 1s sig false
FAIL
FAIL    os  0.428s

Paging Mr. Signals, @ianlancetaylor.

@bradfitz bradfitz added the Testing An issue that has been verified to require only test changes, not just a test failure. label May 9, 2016
@bradfitz bradfitz added this to the Go1.7Maybe milestone May 9, 2016
@bradfitz
Copy link
Contributor Author

This happens much more often on the new OS X 10.9 builder.

I also notice leftover spinning testprogcgo.exe processes sometimes. (Related?)

@ianlancetaylor
Copy link
Member

I have not been able to recreate this with gomote. I have a theory and will send a CL, but it's just a logical guess, not something I can demonstrate will work.

@gopherbot
Copy link
Contributor

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

@ianlancetaylor
Copy link
Member

Maybe fixed.

gopherbot pushed a commit that referenced this issue May 16, 2016
Issue #15613 points out that the darwin builders have been getting
regular failures in which a process that should exit with a SIGPIPE
signal is instead exiting with exit status 2. The code calls
runtime.raise. On most systems runtime.raise is the equivalent of
pthread_kill(gettid(), sig); that is, it kills the thread with the
signal, which should ensure that the program does not keep going. On
darwin, however, runtime.raise is actually kill(getpid(), sig); that is,
it sends a signal to the entire process. If the process decides to
deliver the signal to a different thread, then it is possible that in
some cases the thread that calls raise is able to execute the next
system call before the signal is actually delivered. That would cause
the observed error.

I have not been able to recreate the problem myself, so I don't know
whether this actually fixes it. But, optimistically:

Fixed #15613.

Change-Id: I60c0a9912aae2f46143ca1388fd85e9c3fa9df1f
Reviewed-on: https://go-review.googlesource.com/23152
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang locked and limited conversation to collaborators May 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Development

No branches or pull requests

3 participants