MSan use-after-destroy does not poison objects with implicit destructors #596
Comments
|
You probably meant with trivial implicit destructors. |
|
Is there a test case? |
|
Another possible approach would be to track the place(s) in CodeGen where a destructor call for an object is be emitted, and, if the object has no destructor, call the poisoning function directly. |
|
Test case in clang/test/CodeGenCXX/sanitize-dtor-generated.cpp fails currently. |
Summary: If class or struct has not declared a destructor, no destructor is emitted, and members are not poisoned after destruction. This case highlights bug in current implementation of use-after-dtor poisoning (detailed in google/sanitizers#596). Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12616 Only check simplest object for existence of sanitizing callback. Rename test. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247025 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: If class or struct has not declared a destructor, no destructor is emitted, and members are not poisoned after destruction. This case highlights bug in current implementation of use-after-dtor poisoning (detailed in google/sanitizers#596). Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12616 Only check simplest object for existence of sanitizing callback. Rename test. git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@247025 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: If class or struct has not declared a destructor, no destructor is emitted, and members are not poisoned after destruction. This case highlights bug in current implementation of use-after-dtor poisoning (detailed in google/sanitizers#596). Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12616 Only check simplest object for existence of sanitizing callback. Rename test.
|
Do we really want to poison trivially-destructable objects? AFAIK, they are the preferred (safe) way to avoid destruction-order issues among globals. Among other things, use-after-dtor of trivially-destructable globals is allowed by Google's style guide. |
According to a memory-safety-dev@ discussion accessing a trivially-destructed field (e.g. a raw pointer, while the pointee is still alive) will be Undefined Behavior in C++20. But even before C++20 it seems undesirable that changing a raw pointer |
|
Interesting. It seems pretty easy to implement, too: this loop needs to poison trivially destructible fields in order instead of doing that in bulk before the loop. It can be a bit tricky to merge poisoning calls for adjacent members. For pre-c++20 that would have be under a flag. @vitalybuka FYI |
During code generation, no destructor exists to emit a destructor body for, so no members are poisoned. In order to do, a destructor must be generated for this object.
The creation of implicit destructors occurs during semantic analysis (clang/sema/). However, this step has no access to command line options.
Either semantic analysis must have access to the command line options, to check for msan and emit the required destructor, or another approach must be taken.
The text was updated successfully, but these errors were encountered: