-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/compile: //go:norace for ASAN and other instrumentation #64310
Comments
I wonder if this related to #64257 |
Not directly related, although it can be, e.g. it is possible that in order to make all tests passing some function needs to be marked no-instrumentation. |
@znkr The reason for allocating memory may be that when -asan is turned on, the I'm a little curious why no additional memory is allocated after disabling inlining. Does anyone know about this? Thanks. |
Thank you, that's probably it. The code is unsafe.Pointer heavy out of necessity. I suspect there's no annotation to turn that off? |
Thanks. There is |
Thank you! I don't have time to test this right away, but I'll get to it eventually and will report back. |
This worked, thank you very much! |
What version of Go are you using (
go version
)?tip
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?Linux with GOARCH='amd64' and GOARCH='arm64'
What did you do?
Our Go toolchain contains a patch that allows handling Go runtime crashes for reporting. Code that needs to run as part of that patch is very restricted. The biggest restriction is that it doesn't allow memory allocation. It's possible to write Go code that doesn't allocate memory, but it's near impossible when the code is instrumented. For example, to make the crash handling work with the race detector, all functions have to be annotated with
//go:norace
.We're now running into this problem again when enabling ASAN using
-asan
. The problem is that when ASAN is enabled, the existing code starts to allocate memory where it doesn't without the instrumentation. My best guess is that the ASAN instrumentation leads to different escape analysis results. (I suspected inlining decisions as well, but I don't see any additional allocations when I disable inlining completely).It would help a lot to be able to either disable ASAN instrumentation for crash handling functions with
//go:noasan
or, even better, to disable all instrumentation with, say,//go:noinstrumentation
./cc @cherrymui, @dr2chase
The text was updated successfully, but these errors were encountered: