runtime: pageBits test failure on 386-linux #42053
Comments
ianlancetaylor
changed the title
ianlancetaylor
added
the
NeedsInvestigation
|
CC @mknyszek |
|
Interestingly enough, this isn't a failure in the function being tested, but instead in actually generating the data structure for the test. As a result, I suspect this is benign (i.e. there likely isn't an actual non-test bug here), but I'm surprised that this isn't showing up on the trybots and in CI. I tried to reproduce locally and I was unable to at tip or at 1.15.3. Though, I don't have access to 386 hardware, just amd64 and |
|
Failing everywhere: On virtualized x86 systems (Host is x86_64) and real x86 hardware (just finished testing on Pentium 4 Prescott which is 32bit only and Atom N550 which supports 64bit but is running x86 Linux). |
|
There's only three tests where the layout for the bitmap to be tested is not constant, and they're the hugepage tests. Can you please confirm that it's the hugepage tests that are failing by running the following command and sharing the output? (where "go" is in your development GOROOT at bin/go) Also, what's the hugepage size used for THP on these platforms? That should help me track down what exactly the issue is and I can fix it. |
|
|
Great, thank you so much for the quick turnaround. That'll help a lot. |
|
Change https://golang.org/cl/263837 mentions this issue: |
|
Sorry for the delayed response, the problem was fairly easy to find. The tests were assuming that a huge page wouldn't be exactly Would you mind trying out https://golang.org/cl/263837 to ensure that the new test passes? I can stub the value in and show that it works, but I'd like to make sure the problem is solved on your end. |
Thank you very much! |
|
Hi,should this test failure be considered serious enough that it prevents go 1.14.x and 1.15.x from being sent to Gentoo's stable users on x86? If so, is there any chance of backporting the fix to these versions? Thanks much, William |
|
It only affects folks working on Go itself (or a fork, I suppose) on one of these platforms. The actual code that a user would run works fine as there's no real bug here outside of tests. On the other hand, it's a very safe change because it only modifies test code so I'm certainly not opposed to backporting personally. I'm honestly not sure how the cost/benefit situation of another change in the point releases works out. Let's ask @dmitshur maybe? |
|
Thank you for clarification, for Gentoo Linux, we will move on now that we know that this is just a test failure. |
|
@mknyszek You're right that test-only fixes are generally safer to backport, which makes it an easier decision. That said, while okay in small numbers, we don't want to do it too frequently. We do it occasionally when there is a specific need, usually in order to fix false-positive failures during pre-release testing and trybots that run on cherry-pick CLs. If there's a good reason to backport a test-only fix, we will certainly consider it. You can do a search for test-only packports we've approved with this query. In this case, it seems like the most important aspect here was to understand that this issue was in the test itself, and not a problem in the real code. So as I understand there isn't a strong need to backport the test fix anymore, especially since it doesn't affect testing done by our current builders. But if I'm missing something, please request a backport and provide a rationale. Also CC @golang/release FYI. |
I was trying to build go-1.14.9 and go-1.14.10 on Gentoo, but tests failed. So I tried 1.15.3 and git master -- the same. See the failure below.
This is a x86 system.
Does this issue reproduce with the latest release?
Yes, I tried building from git master (
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I am trying to run test suite.
What did you expect to see?
No test failures.
What did you see instead?
Test failuresOutputThe text was updated successfully, but these errors were encountered: