-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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/cgo/internal/testsanitizers,x/build: LUCI clang15 builders failing #65469
Comments
Change https://go.dev/cl/561595 mentions this issue: |
This will take some time to propagate. I suspect it should look OK by tomorrow. |
I added zlib to the image but it wasn't enough. I tracked down the problem to the fact that the official LLVM project's release of clang does NOT build llvm-symbolizer with zlib support. This is unfortunate. The only alternative is to use a different clang. The nice thing about the current system I set up for LUCI is that clang is using just the regular official LLVM release maintained easily in CIPD, so it's easy to update, change, and manage. A few available options (all unfortunate) are:
However, there's a different direction we can take. The ASAN tests already skip checking for file and line numbers (symbolized results) in the output on old GCC versions. However, AFAICT, the version of GCC on our builders does actually symbolize the output. I think the primary purpose of these tests is to make sure our debug information is working correctly, not necessarily integration with specific toolchains. So, theoretically, we have coverage on our debug information working properly already. What I propose:
Based on the thread I found this request seems reasonable to the LLVM maintainers. I'll note that apparently the exact LLVM configuration used in the release is up to whoever is doing the release anyway, so my assumption is that there are already some inconsistencies in their process, and requiring zlib probably wouldn't be too hard on users of clang. But I don't know. |
Change https://go.dev/cl/562675 mentions this issue: |
Change https://go.dev/cl/562538 mentions this issue: |
@gopherbot Please open backport issues for Go 1.21 and Go 1.22. The LUCI clang builder on those branches is currently broken, and we should cherry-pick the fix applied here. |
Backport issue(s) opened: #65640 (for 1.21), #65641 (for 1.22). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/563015 mentions this issue: |
Change https://go.dev/cl/562999 mentions this issue: |
…tion checking for clang Pending a resolution to #65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For #65606. For #65469. Fixes #65640. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:go1.21-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit d94ab59) Reviewed-on: https://go-review.googlesource.com/c/go/+/562999
…tion checking for clang Pending a resolution to #65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For #65606. For #65469. Fixes #65641. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:go1.22-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit d94ab59) Reviewed-on: https://go-review.googlesource.com/c/go/+/563015
Pending a resolution to golang#65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For golang#65606. Fixes golang#65469. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…tion checking for clang Pending a resolution to golang#65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For golang#65606. For golang#65469. Fixes golang#65641. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:go1.22-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit d94ab59) Reviewed-on: https://go-review.googlesource.com/c/go/+/563015
…tion checking for clang Pending a resolution to golang#65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For golang#65606. For golang#65469. Fixes golang#65641. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:go1.22-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit d94ab59) Reviewed-on: https://go-review.googlesource.com/c/go/+/563015
I've been working on bringing up the clang15 builders this week on LUCI, and the ASAN tests are failing because of a failure to symbolize the output. I've narrowed down the root cause to a missing zlib dependency (in hindsight, pretty obvious from the output) in our image.
Filing an issue to track fixing this. It's especially important because these builders are run in an advisory manner as part of the release.
The text was updated successfully, but these errors were encountered: