Skip to content
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

cmd/link: TestDWARF failing on freebsd/arm since August 2020 #43197

Closed
aclements opened this issue Dec 15, 2020 · 6 comments
Closed

cmd/link: TestDWARF failing on freebsd/arm since August 2020 #43197

aclements opened this issue Dec 15, 2020 · 6 comments

Comments

@aclements
Copy link
Member

@aclements aclements commented Dec 15, 2020

The freebsd-arm-paulzhol builder has been failing since August with

--- FAIL: TestDWARF (8.89s)
    dwarf_test.go:41: cmd/link is stale - run go install cmd/link
FAIL
FAIL	cmd/link	125.383s

Unfortunately, the builder has been mostly out-to-lunch for a long time (cc @paulzhol ). The last successful run was 4489f4b on June 5th and the first failing run was 8acbe4c on August 22nd.

@golang/osp-team , what should we do about this builder and/or the freebsd/arm port?

cc @cherrymui @jeremyfaller @thanm since it's a linker test. But the builder is effectively inaccessible, so it would be very hard to test a fix.

@paulzhol
Copy link
Member

@paulzhol paulzhol commented Dec 15, 2020

@aclements I've tried to debug it in #41101 but without much success. I will gladly provide access / bring it back online. I was planning to upgrade it to FreeBSD 12.2.

@jeremyfaller
Copy link
Contributor

@jeremyfaller jeremyfaller commented Dec 15, 2020

I think I've seen that failure when there was non-reproducible object files. I believe that there was a bug I introduced sometime during that pass/fail window that Cherry fixed, and that test should universally pass.

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 15, 2020

Personally I don't really like that stale check. I understand that it was there to catch the situation where someone is developing the linker locally, runs go test without go installing the linker first, which will get a wrong result. But I don't think it belongs to that particular test.

  • it isn't useful for a builder or CI system (where the toolchain is always freshly built)
  • if we want to do that, it'd probably better be an init function or TestMain.

It is true that it is weird that the linker is reported stale there (and not earlier by cmd/dist, if it is really stale). I could try to debug. But I also want to bring up the idea that we just remove that staleness check.

@paulzhol
Copy link
Member

@paulzhol paulzhol commented Dec 15, 2020

As I understand it, the test is already disabled for darwin-amd64 builders by https://golang.org/cl/223925.

@bcmills
Copy link
Member

@bcmills bcmills commented Dec 15, 2020

@cherrymui

it isn't useful for a builder or CI system (where the toolchain is always freshly built)

For the moment, at least, the staleness check is useful in CI because it helps to detect cases where the build of the toolchain is somehow incomplete, corrupted, or out of sync (such as #33598 and #35740, which have yet to be diagnosed and fixed).

It's fine to remove the check if it isn't actually verifying a property relevant to the test, but if the staleness of cmd/link actually is relevant to the test then the check should stay — if we remove it, that just papers over some underlying problem that remains for the builder.

@aclements
Copy link
Member Author

@aclements aclements commented Dec 15, 2020

Sorry, I'd missed that this was already reported in #41101 (I searched around but somehow didn't find that). Let's close this as a dup and move the conversation over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants