[libcxx] r208319 - Add Address Sanitizer support to std::vector
Kostya Serebryany
kcc at google.com
Mon May 12 07:27:00 PDT 2014
On Mon, May 12, 2014 at 5:29 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Mon, May 12, 2014 at 3:45 PM, Stephan Tolksdorf <st at quanttec.com>wrote:
>
>> On 12.05.14 13:13, Kostya Serebryany wrote:
>>
>>> Do you have a test that demonstrates that? That would be very helpful.
>>>
>>
>> In push_back for example, you annotate that the length increases by 1,
>> but then you don't undo that annotation if the copy constructor of the
>> element throws an exception. Afterwards the sanitizer can't properly check
>> accesses to the end of the vector and the next time the vector calls
>> __sanitizer_annotate_contiguous_container it will pass a wrong old_mid
>> pointer.
>>
>
> Trying to build a test case with libc++ and exceptions... (not trivial,
> will take some time)
>
Reproduced. (we have very little code with exceptions so this has avoided
our testing efforts :)
Any suggestion for the fix?
#include <vector>
#include <assert.h>
#include <iostream>
#include <sanitizer/asan_interface.h>
using namespace std;
class X {
public:
X(const X &x) {
if (x.a == 42) throw 0;
a = x.a;
}
X(char arg): a(arg){}
char get() const { return a; }
private:
char a;
};
int main() {
vector<X> v;
v.reserve(2);
v.push_back(X(2));
assert(v.size() == 1);
try {
v.push_back(X(42));
assert(0);
} catch (int e) {
assert(v.size() == 1);
}
assert(v.size() == 1);
assert(v[1].get() != 777);
char *p = (char*)v.data();
assert(!__asan_address_is_poisoned(p));
assert(__asan_address_is_poisoned(p+1));
}
>
>
>>
>> And an unrelated issue: the documentation for __sanitizer_annotate_contiguous_container
>> states that the complete buffer should be unpoisened before it is
>> deallocated. This doesn't seem to be happening in the destructor or in the
>> deallocate function.
>
> Here we rely on the fact that vector is using the default allocator, which
> immediately calls delete, which itself unpoisons the memory chunk.
>
> --kcc
>
>>
>>
>> - Stephan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140512/665c2a24/attachment.html>
More information about the cfe-commits
mailing list