-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
infra: Set -ftrivial-auto-var-init=pattern for address sanitizer #5879
Conversation
I tested with an example bug that the crash is now deterministic with a single iterations. Previously a few iterations (~8) out of the 100 max (see commit 66b1911) were needed. |
Happy to test more if there are any ideas. Also, I am wondering if I am missing any downside of this? |
Thanks @MarcoFalke for doing this. I think there will be a lot of back and forth on this. @morehouse @kcc @inferno-chromium @oliverchang @asraa what do you think of this? |
I think this change is net positive. Would like to hear other opinions though. One negative:
bool x; // auto-inited to true
if (x) {
...
} else {
// Some bug here
...
} |
Yea, may miss some bugs. |
It looks like For testing:
(without |
LGTM |
Pushed a fix for |
Anything left to do here? :) |
Reading uninitialized memory is undefined behaviour, thus non-deterministic. Non-determinism makes it harder to reproduce a bug. To fix some cases of non-determinism, I suggest to add
-ftrivial-auto-var-init=pattern
to the address sanitizer.Obviously not all uninitialized reads can be caught by this and Valgrind or MSAN are still recommended tools to fight this class of bug.
Even though
-ftrivial-auto-var-init=pattern
will hide some bugs from Valgrind or MSAN, those tools are largely incompatible with ASAN, so adding the option to the ASAN flags should be fine.