x/text/language: TestBestMatchAlloc failures with "got 1.000000; want 0" #45809
Labels
FrozenDueToAge
help wanted
NeedsFix
The path to resolution is known, but the work has not been done.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Milestone
Comments
bcmills
added
Testing
dpaks
added a commit
to dpaks/text
that referenced
this issue
May 22, 2021
The test calls testing.AllocsPerRun with a count of 1. AllocsPerRun sets runtime.GOMAXPROCS to 1, but it doesn't prevent the runtime from descheduling a goroutine and performing an allocation somewhere in the background. This commit changes the test to use a number of runs large enough to average away the occasional noisy allocation. Fixes golang/go#45809
|
Change https://golang.org/cl/321737 mentions this issue: |
xhit
pushed a commit
to xhit/text
that referenced
this issue
Oct 10, 2022
AllocsPerRun sets runtime.GOMAXPROCS to 1, but it doesn't prevent the runtime from descheduling a goroutine and performing an allocation somewhere in the background. This commit changes the test to use a number of runs large enough to average away the occasional noisy allocation. Fixes golang/go#45809 Change-Id: Ibf904016d0c067740469c8e861079611440222a1 GitHub-Last-Rev: 1606b69 GitHub-Pull-Request: golang#23 Reviewed-on: https://go-review.googlesource.com/c/text/+/321737 Reviewed-by: Bryan C. Mills <bcmills@google.com> Trust: Michael Knyszek <mknyszek@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2021-04-11T12:01:40-c2d28a6/linux-ppc64-buildlet
2021-04-11T12:01:40-c2d28a6/linux-ppc64le-buildlet
2021-04-11T12:01:40-c2d28a6/linux-s390x-ibm
2020-11-18T01:06:06-4482a91/linux-ppc64-buildlet
The test calls
testing.AllocsPerRunwith a count of 1:https://github.com/golang/text/blob/e328d63cff14134669501e0e154e4f141c784322/language/match_test.go#L245-L247
That pattern is basically guaranteed to be flaky:
AllocsPerRunsetsruntime.GOMAXPROCSto 1, but it doesn't have any way to prevent the runtime from descheduling a goroutine and performing an allocation somewhere in the background, and it isn't at all obvious that the test has enough control over its environment to guarantee that no other goroutine that might allocate can be scheduled at that point.The test should be changed to use a number of runs large enough to average away the occasional noisy allocation.
The text was updated successfully, but these errors were encountered: