[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