mauri870
commented
12 months ago cc @golang/wsl
Closed qiulaidongfeng closed 2 weeks ago
mauri870
commented
12 months ago cc @golang/wsl
bcmills
commented
12 months ago (CC @golang/windows)
bcmills
commented
12 months ago This turns out not to be specific to WSL2: this also fails on Linux.
bcmills
commented
12 months ago On linux/amd64 (no WSL involved):
zhangfannie
commented
12 months ago Allocs-related tests fail because when -asan is turned on, the -checkptr option is implicitly set to 2, which is implemented by CL 393315, so that some stack objects with usafe.Pointer operation will escape to the heap, resulting in additional heap allocation.
zhangfannie
commented
12 months ago 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.
gopherbot
commented
12 months ago Change https://go.dev/cl/543837 mentions this issue: runtime: change the name of variables in asan-related assembly funtions
bcmills
commented
12 months ago As for the issue of allocs tests, we may need to skip these tests when -asan is on. Does anyone have any other ideas?
testenv.SkipIfOptimizationOff seems like it fits the bill — is there some way to make testenv.OptimizationOff return true if the build is using MSAN or ASAN?
zhangfannie
commented
12 months ago
testenv.SkipIfOptimizationOffseems like it fits the bill — is there some way to maketestenv.OptimizationOffreturn true if the build is using MSAN or ASAN?
This is a good one! Maybe we can control it through build flags. Please see the changes below. Thank you.
diff --git a/src/internal/testenv/noopt.go b/src/internal/testenv/noopt.go
index ae2a3d011a..68f7bbdbb7 100644
--- a/src/internal/testenv/noopt.go
+++ b/src/internal/testenv/noopt.go
@@ -2,7 +2,7 @@
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
-//go:build noopt
+//go:build noopt || asan || msan
testenv.SkipIfOptimizationOffseems like it fits the bill — is there some way to maketestenv.OptimizationOffreturn true if the build is using MSAN or ASAN?
@bcmills When I was about to write the fixing code, I found that this idea was not very good. Because when we use testenv.SkipIfOptimizationOff function to skip some tests that will fail when -asan is turned on, then these tests will not run when -noopt is turned on. I guess that is not what we expected, right?
Perhaps we may need to create a new SkipIfOptimizationOff-like function for asan, called SkipAsanOn or something else. What do you think? Thank you.
bcmills
commented
11 months ago @zhangfannie, I think it would be fine to spuriously skip alloc tests on the -noopt builders too — otherwise, won't those allocation tests also fail if the implementation details of the compiler change in a way we don't care about?
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. 😅
zhangfannie
commented
11 months ago @bcmills Perhaps we could create an exported function called runtime.AsanEnabled() and use this function to skip these failing tests. what do you think? Thank you.
mauri870
commented
11 months ago @zhangfannie Looks like you reached the same dead end as me, in https://github.com/golang/go/issues/64256.
I ended up filling https://github.com/golang/go/issues/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
zhangfannie
commented
11 months ago @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.
I think this is a good approach. Thank you for doing this.
mauri870
commented
9 months ago I got back to working on this after the internal/asan package was submitted.
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
qiulaidongfeng
commented
9 months ago 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.
Test fail of cmd/internal/moddeps maybe a false alarm? I can't reproduce it in wsl2.
mauri870
commented
9 months ago 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.
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.
qiulaidongfeng
commented
9 months ago My machine（wsl2） output
runtime
traceback: unexpected SPWRITE function asancall
fatal error: tracebackcgo
--- FAIL: Test10303 (0.00s)
test.go:1777: C int* argument on stack
test.go:1780: C intptr argument on stack
test.go:1783: C void* argument on stack
test.go:1786: C struct field pointer on stack
FAIL
FAIL cmd/cgo/internal/test 2.019sChange https://go.dev/cl/622855 mentions this issue: all: skip allocation counting tests with -asan and -msan
mknyszek
commented
2 weeks ago There are still a few flaky tests. Namely:
TestNewOSProc0 TestGdb TestCgoPprof TestCgoSigfwd
These should probably just get their own issues at this point, so leaving this closed.
gopherbot
commented
2 weeks ago Change https://go.dev/cl/623176 mentions this issue: runtime: skip TestNewOSProc0 with asan and msan
mknyszek
commented
2 weeks ago I have a patch out for TestNewOSProc0. The rest don't actually seem like real problems themselves, but rather collateral damage from some nearby test, possibly running in parallel.
Notably, the TestGdb* and TestCgo* tests all shell out to programs built without -asan, and the failure is a bad signal in the main test binary, which is running pure Go code at that point. If there was a serious issues with pure Go code, I would expect other packages to be failing, which is why I think it has to be bad test somewhere in the tests running in parallel.
gopherbot
commented
2 weeks ago Change https://go.dev/cl/623336 mentions this issue: runtime: skip TestMemmoveOverflow with asan
gopherbot
commented
2 weeks ago Change https://go.dev/cl/623957 mentions this issue: [release-branch.go1.23] all: skip and fix various tests with -asan and -msan
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 envOutputWhat did you do?
go tool dist test -asan
What did you expect to see?
test pass.
What did you see instead?
output.txt