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
internal/poll: TestSplicePipePool failures with "at least one pipe is still open" on linux-arm #48066
Comments
This test was added for Go 1.17 (March 9, in CL 271537 for #42740), so these failures represent at least a regression in test flakiness in the current release (CC @golang/release). A rollback of the flaky test in CL 308089 was abandoned in favor of an attempt to fix the test in CL 308329. The failure rate seems to have been partially obscured by the low rate of changes during the Go 1.17 code freeze. It is not clear to me whether the test failures represent a defect in the test itself or an incomplete fix for #42740. Since this flakiness is new as of Go 1.17, I think a fix for it should at least block the next release. |
Given that at least one pipe was not closed in the test, it could only be either that the finalizers for each pipe didn't work properly on some platforms, or that the If it is the latter mentioned above, then this issue has been there since the day |
Per https://pkg.go.dev/runtime#SetFinalizer (emphasis mine):
If the test depends on a finalizer actually executing, it is depending on a property of the runtime that is not guaranteed to hold — it should probably have extra scrutiny from the runtime team. |
It seems to have been working well on https://github.com/golang/go/blob/go1.17/src/sync/pool_test.go#L100-L135 with |
|
I want to debug and reproduce this test failure on those platforms, but I don't have any of those machines with ARM processors on hand now, is there a way for me to run the test on machines of golang build farm without interfering with the routine builds? |
Another thought about improving test code is to leverage epoll to monitor all pipe fds and when we receive the sufficient amount (equal to the amount of pipes) of |
Besides, I just found a analogical discussion at #26049 |
Just a note on the original issue: the scaleway builders no longer exist, as Scaleway dropped ARM support. @panjf2000 We aren't granting new access to our builders at this time. It looks like it also failed today on The only other special thing about that builder is the following environment variables, which can also be seen in the linked logs:
|
Change https://golang.org/cl/348579 mentions this issue: |
For #48066 Change-Id: I1152a1c15756df35b71b27d3e7025d97da9e70b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/348579 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
It appears that all finalizers occasionally failed to execute on the android platform for some unknown reasons, take a look at this test log, where none of the finalizers executed. |
I think you are misreading the log. Of the various descriptors to check, only descriptor This makes me wonder whether descriptor |
I did misread the log and sorry about that, it was the minimum fd that was still alive, which makes it stands a good chance of being reused inside the process, I will submit a CL to improve the |
Change https://golang.org/cl/349774 mentions this issue: |
2021-08-26T22:37:54-967a801/android-arm-corellium
2021-08-26T20:39:56-af80af2/android-arm-corellium
2021-08-24T22:23:12-54cdef1/android-arm-corellium
2021-08-22T13:11:50-96d816c/android-arm-corellium
2021-08-17T16:22:15-cf12b0d/android-arm-corellium
2021-08-11T22:07:50-dea23e9/android-arm-corellium
2021-05-26T22:41:55-0fbecec/linux-arm-scaleway
2021-04-29T13:24:00-eb3fe28/linux-arm-scaleway
See previously #45782, #45059 (@panjf2000 @ianlancetaylor @bradfitz).
The text was updated successfully, but these errors were encountered: