-
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
all: go tool dist test -asan
fails many tests
#64257
Comments
cc @golang/wsl |
(CC @golang/windows) |
This turns out not to be specific to WSL2: this also fails on Linux. |
go tool dist test -asan
fails many tests
On
|
Allocs-related tests fail because when |
For the bug in the assembly function, I will submit a patch to fix it. As for the issue of allocs tests, we may need to skip these tests when -asan is on. Does anyone have any other ideas? Thank you. |
Change https://go.dev/cl/543837 mentions this issue: |
|
Variables in functions implemented in assembly should have the same names as when they were defined. The names of some variables in asan-related assembly functions do not follow the above rule, which will cause the runtime test to fail. This CL fixes this issue. Updates #64257 Change-Id: I261f4db807d25e460513ef1c92cd1b707cdd1a16 Reviewed-on: https://go-review.googlesource.com/c/go/+/543837 Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
This is a good one!
|
@bcmills When I was about to write the fixing code, I found that this idea was not very good. Because when we use Perhaps we may need to create a new SkipIfOptimizationOff-like function for asan, called SkipAsanOn or something else. What do you think? Thank you. |
@zhangfannie, I think it would be fine to spuriously skip alloc tests on the If real users care about reducing allocations, presumably they should build their programs in a way that does not explicitly prevent the compiler from reducing allocations. 😅 |
@bcmills Perhaps we could create an exported function called |
@zhangfannie Looks like you reached the same dead end as me, in #64256. I ended up filling #64611 which I believe is a good addition that would make it much easier to deal with these test allocation cases moving forward. I would be glad to hear your opinions on this. cc @bcmills |
I think this is a good approach. Thank you for doing this. |
I got back to working on this after the There are many tests that fail with wrong allocation counts, and these can now be skipped by checking asan.Enabled. I'm attaching the output of tests that are still failing. I'm not sure if they are false positives and should be skipped as well. There is a AddressSanitizer stack-overflow in runtime, failures in pprof tests and test10303 in src/cmd/cgo/internal/test. Sending as an attachment because Firefox crashes if I try to paste the contents |
Test fail of cmd/internal/moddeps maybe a false alarm? I can't reproduce it in wsl2. |
Sorry, please ignore the dep tests, my go tree is dirty. The ones that I'm worried about are cgo, runtime and pprof. |
My machine(wsl2) output runtime
cgo
|
Change https://go.dev/cl/622855 mentions this issue: |
There are still a few flaky tests. Namely: TestNewOSProc0 These should probably just get their own issues at this point, so leaving this closed. |
Change https://go.dev/cl/623176 mentions this issue: |
I have a patch out for Notably, the |
These fail for the same reason as for the race detector, and is the most frequently failing test in both. For #70054. For #64257. For #64256. Change-Id: I3649e58069190b4450f9d4deae6eb8eca5f827a3 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15,gotip-linux-amd64-msan-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/623176 TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/623336 mentions this issue: |
On a whim I decided to investigate the possibility of whether the flakiness on the asan builder was due to a concurrently executing test. Of the most recent failures there were a few candidates, and this test was one of them. After disabling each candidate one by one, we had a winner: this test causes other concurrently executing tests, running pure Go code, to spuriously fail. I do not know why yet, but this test doesn't seem like it would have incredibly high value for ASAN, and does funky things like MAP_FIXED in recently unmapped regions, so I think it's fine. For #70054. For #64257. Change-Id: Ib9a84d9b69812e76c390d99b00698710ee1ece1a Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-asan-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/623336 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/623957 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go tool dist test -asan
What did you expect to see?
test pass.
What did you see instead?
output.txt
The text was updated successfully, but these errors were encountered: