Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Details
- Reviewers
eugenis vitalybuka kcc - Commits
- rGf113deaa3cf3: [MSan] Enable use-after-dtor instrumentation by default.
rL322221: [MSan] Enable use-after-dtor instrumentation by default.
rC322221: [MSan] Enable use-after-dtor instrumentation by default.
rCRT322221: [MSan] Enable use-after-dtor instrumentation by default.
Diff Detail
Event Timeline
clang/include/clang/Driver/Options.td | ||
---|---|---|
854 ↗ | (On Diff #115261) | I'd recommend to split patch in two:
|
clang/lib/Driver/SanitizerArgs.cpp | ||
492 | Can you use parsing similar to AsanUseAfterScope at line 645 | |
compiler-rt/test/msan/dtor-bit-fields.cc | ||
3 ↗ | (On Diff #115261) | Please keep -fsanitize-memory-use-after-dtor in dtor* tests. |
compiler-rt/test/msan/use-after-dtor.cc | ||
13 | Probably we need one test which check that we stop detecting bugs with |
clang/test/Driver/fsanitize.c | ||
---|---|---|
175 | Somewhere we need to have test that default is ON or OFF. |
compiler-rt/test/msan/use-after-dtor.cc | ||
---|---|---|
13 | Right. |
Looking at __sanitizer_dtor_callback implementation, this change will add a (fast) stack unwind in every destructor. In extreme cases (like a tight loop doing string operations) it could be bad for performance. I've seen ~15% AFAIR.
I haven't looked at performance, but I'll take a look at your internal bug. Until that is resolved, this can be on hold.
Patch is out-of-date. But the flag has been enabled internally for over a month with no issues. I'll update this patch soon, so we can flip the default here.
- Enable use-after-dtor instrumentation by default.
- Make sanitize-no-dtor-callback.cpp test fail with UAD instrumentation.
- Update test cases to reflect new default.
Can you use parsing similar to AsanUseAfterScope at line 645