-
Notifications
You must be signed in to change notification settings - Fork 18k
os/exec: test timeouts on openbsd #19547
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
Comments
/cc @mdempsky for OpenBSD |
Found this during CL 38761 trybot run https://storage.googleapis.com/go-build-log/99b40820/openbsd-amd64-60_178381c2.log Alex |
Another one during CL 39950: https://storage.googleapis.com/go-build-log/772dd722/openbsd-amd64-60_91338d40.log |
It looks like the timeouts always happen in TestIgnorePipeErrorOnSuccess. Also, TestWaitid is always blocked waiting in t.Parallel. (The latter seems expected: TestIgnorePipeErrorOnSuccess is a serial test, so TestWaitid logically has to wait for it to finish, but I don't really understand the inner working of package testing.) Casually reading through the OpenBSD-specific code, I don't see anything obviously wrong. I'll have to try running the code on an actual OpenBSD box and see if I can reproduce a failure under ktrace. From the trace, it seems like one of the io.Copy calls (either copying the StringReader to pipe, or pipe to bytes.Buffer) is hanging. That would make me suspect a kqueue issue, but then I'd expect to see the issue on 386 too. One minor observation: OpenBSD 5.7 added functions like pipe2 and dup3 so it's now possible to create FDs with the CLOEXEC flag already set, which would allow us to get rid of a lot of uses of ForkLock. I don't think that's the issue though. |
I created an OpenBSD VM yesterday with the same builder image & ran the test in a loop tens of thousands of times. I did finally get it to fail once, but it wasn't easy. It seems to happen more easily under load, so then I started running tl;dr: reproducible at least. |
We now have both OpenBSD 6.0 and 6.2 builders for GOARCH=386, and both are super flaky in the same way. But both OpenBSD 6.0 and 6.2 are fine for GOARCH=amd64. The amd64 vs 386 builders are the same VM sizes and the VM templates were both auto-generated from the same scripts. There should be no difference between them except the architecture. So what is wrong with our 386 code? (or the OpenBSD 386 kernel perhaps) Current build.golang.org output: (mouseover the architecture heads to see 6.0 vs 6.2) |
Change https://golang.org/cl/84035 mentions this issue: |
… arm5 Updates golang/go#19547 Updates golang/go#22594 Change-Id: I0200eebf39c1fada6c6ce146afacb9d140142c5b Reviewed-on: https://go-review.googlesource.com/84035 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Nevermind, it was just cmd/go tests getting too slow and test timeouts. Column happy now. Not sure how I missed that before. :-( |
Build dashboard:
https://build.golang.org/log/7fc2593c7c90818805f1d623fbe9fa9f3d1d4aec
trybot run:
https://storage.googleapis.com/go-build-log/581bc46b/openbsd-amd64-60_3bfc9d56.log
The text was updated successfully, but these errors were encountered: