cmd/compile: building with -asan generates many more allocations than with other instrumentation modes
#70079
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
mknyszek
added
NeedsInvestigation
|
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
gopherbot
added
the
compiler/runtime
|
Change https://go.dev/cl/622855 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Oct 28, 2024
First, skip all the allocation count tests. In some cases this aligns with existing skips for -race, but in others we've got new issues. These are debug modes, so some performance loss is expected, and this is clearly no worse than today where the tests fail. Next, skip internal linking and static linking tests for msan and asan. With asan we get an explicit failure that neither are supported by the C and/or Go compilers. With msan, we only get the Go compiler telling us internal linking is unavailable. With static linking, we segfault instead. Filed #70080 to track that. Next, skip some malloc tests with asan that don't quite work because of the redzone. This is because of some sizeclass assumptions that get broken with the redzone and the fact that the tiny allocator is effectively disabled (again, due to the redzone). Next, skip some runtime/pprof tests with asan, because of extra allocations. Next, skip some malloc tests with asan that also fail because of extra allocations. Next, fix up memstats accounting for arenas when asan is enabled. There is a bug where more is added to the stats than subtracted. This also simplifies the accounting a little. Next, skip race tests with msan or asan enabled; they're mutually incompatible. Fixes #70054. Fixes #64256. Fixes #64257. For #70079. For #70080. Change-Id: I99c02a0b9d621e44f1f918b307aa4a4944c3ec60 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/+/622855 Reviewed-by: Cherry Mui <[email protected]> TryBot-Bypass: Michael Knyszek <[email protected]>
|
In triage, I am told this may be totally intentional. ASAN doesn't work quite so well with stack pointers, so it intentionally forces a lot more to the heap, like every pointer converted to an |
|
Change https://go.dev/cl/623957 mentions this issue: |
|
Change https://go.dev/cl/654835 mentions this issue: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not really sure what the trouble is yet, but this does seem to be true given how many allocation count tests failed on
asanbut not withraceormsan.For example, tests failed on the new
msanbuilder: https://ci.chromium.org/ui/p/golang/builders/ci/gotip-linux-amd64-msan-clang15/b8732829196319772801/overviewThis mostly aligns with skips for
racemode.But with
asan, there are many more: https://ci.chromium.org/ui/p/golang/builders/ci/gotip-linux-amd64-asan-clang15/b8732829195285565617/test-results?sortby=&groupby=These tests will be skipped for now, so this is low priority. But anyone interested in improving the performance of
asanmode might consider looking here first.Discovered during #70054.
The text was updated successfully, but these errors were encountered: