-
Notifications
You must be signed in to change notification settings - Fork 18k
internal/fmtsort: channel tests make specious assumptions about object ordering #49431
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
Yes, it looks like that's what's happening. Not sure how to make the test robust without essentially duplicating the package's own logic, which is unfortunate. Ideas welcome. |
Change https://golang.org/cl/361918 mentions this issue: |
It seems to me that sorting dynamically-allocated pointers by pointer value is inherently nondeterministic, given Go's memory model: if the values are relocated during the test, they will end up out of order. (That is: this test, strictly speaking, requires #46787.) The fact that the language provides no way to statically allocate channel values further complicates the matter (compare #28366). Without a pinning API, I think this test fundamentally cannot be written in a way is guaranteed by the language spec to be deterministic. |
Reopening to make this issue about making this test more robust. |
@randall77, you reopened this bug. What is it meant to track now? Use of a Pinner? |
Yes, just to make the test (and the actual code, maybe?) less dependent on object addresses. I'm not entirely clear on how that would happen, exactly. Maybe there's nothing concrete to do here. |
Complete TODO. For golang#49431 Change-Id: Ifc79741ad44cd9631be49d4674db0ee52bbf6486
Change https://go.dev/cl/528796 mentions this issue: |
Complete TODO. For golang#49431 Change-Id: Ifc79741ad44cd9631be49d4674db0ee52bbf6486
Complete TODO. For golang#49431 Change-Id: Ifc79741ad44cd9631be49d4674db0ee52bbf6486
Complete TODO. For golang#49431 Change-Id: Ifc79741ad44cd9631be49d4674db0ee52bbf6486
Complete TODO. For golang#49431 Change-Id: Ifc79741ad44cd9631be49d4674db0ee52bbf6486
Complete TODO. For #49431 Change-Id: I1399205e430ebd83182c3e0c4becf1fde32d433e GitHub-Last-Rev: 02cdea7 GitHub-Pull-Request: #62673 Reviewed-on: https://go-review.googlesource.com/c/go/+/528796 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Commit-Queue: Keith Randall <khr@golang.org> Run-TryBot: qiulaidongfeng <2645477756@qq.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
@qiulaidongfeng: is this fixed as of https://go.dev/cl/528796, or is there more to do? |
I'm going to close, I think this is done. |
On the longtest builders:
I think this is happening because
chans[0]
is in pointer space higher thanchans[1]
andchans[2]
. It seems that these tests expect channels to sort in the order they are allocated, which isn't necessarily true.@robpike
The text was updated successfully, but these errors were encountered: