You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To implement -asan to detect invalid memory access to the stack object, it does not add readzones around the stack object like the implementation of the heap object, but implicitly sets -checkptr to 2, which is implemented by CL 393315. In this way, all pointer operations on the stack objects will become operations on the escaped heap objects. As we've already supported ASan detection of error memory accesses to heap objects. With this trick, we can use -asan option to report errors on bad stack operations.
However, based on the current implementation, when -asan is turned on, stack objects oprated with unsafe.Pointer will escape to the heap, resulting in additional memory alloctions. This will cause some issues. For example, turning on -asan will cause some tests to fail, see #64257. More seriously, some codes do not allow memory allocation, so -asan cannot be used, see #64310.
So I'm wondering if the implementation of setting -checkptr to 2 is doing more harm than good. I would like to suggest changing this implementation and instead of setting -checkptr to 2, just set -checkprt to 1 like -msan and -race do. But this way, -asan cannot check for invalid memory access to stack objects. If the user wants to use -asan to check, they can explicitly set -checkptr to 2.
The text was updated successfully, but these errors were encountered:
changed the title
proposal: cmd/go: do not implicitly set -checkptr to 2 when -asan is turned on.
proposal: cmd/compile: do not implicitly set -checkptr to 2 when -asan is turned on
Nov 28, 2023
With regards to #64310. The code in question is so special that we can live with annotating every function. We already need to do that for the race detector anyway. That said, it was a bit frustrating to debug that issue.