false negatives with throw/longjmp

[ramosian-glider]

Originally reported on Google Code with ID 258

currently, when throw or longjmp happens, we un-poison the entire thread's
stack to avoid false positives. As the result we may get false negatives
of this kind:
void foo() {
 int stack[20];
 ThrowAndCatch();  // un-poisons the entire stack
 ... stack[21] ... // Not detected
}

We should un-poison only the section of the stack between throw and catch.
(same for lonjmp/setjmp)

Reported by konstantin.s.serebryany on 2014-01-21 09:49:33

[ramosian-glider]

added unittests: 
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/lit_tests/TestCases/throw_catch.cc?revision=199723&view=markup&pathrev=199723

Reported by konstantin.s.serebryany on 2014-01-23 12:41:32

[ramosian-glider]

A very similar situation happens with container-overflow annotations
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140512/105332.html

Reported by konstantin.s.serebryany on 2014-05-13 12:41:40

[danra]

I'm getting CHECK failed with Xcode 7.2.1, only when compiling with libc++:
==32554==AddressSanitizer CHECK failed: /Library/Caches/com.apple.xbs/Sources/clang/clang-700.1.81/src/projects/compiler-rt/lib/asan/asan_poisoning.cc:361 "(((u8)MemToShadow(a))) == ((0))" (0xfc, 0x0)

Stack trace:

#0 0x000000015eace170 in __asan::AsanDie() ()
#1 0x000000015ead1a9d in __sanitizer::Die() ()
#2 0x000000015eace36a in asan::AsanCheckFailed(char const, int, char const, unsigned long long, unsigned long long) ()
#3 0x000000015ead1c32 in sanitizer::CheckFailed(char const, int, char const, unsigned long long, unsigned long long) ()
#4 0x000000015eac8552 in __sanitizer_annotate_contiguous_container ()
#5 0x000000015c46a01f in std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::1::pair<int, int> > >::annotate_contiguous_container(void const, void const, void const, void const) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:842
#6 0x000000015c46c337 in std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >::__annotate_new(unsigned long) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:848
#7 0x000000015c479de8 in std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >::allocate(unsigned long) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:938
#8 0x000000015c4790c2 in std::__1::enable_if<(__is_forward_iterator<std::__1::pair<int, int>>::value) && (is_constructible<std::__1::pair<int, int>, std::__1::iterator_traits<std::__1::pair<int, int>>::reference>::value), void>::type std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >::assign<std::__1::pair<int, int>>(std::__1::pair<int, int>, std::__1::pair<int, int>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:1413
#9 0x000000015c475338 in std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >::operator=(std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > > const&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:1358
#10 my own code, assigning std::vector < std::pair < int, int > > to another vector

I saw a comment in https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/asan_poisoning.cc about the other checks around the failing check being commented-out due to this issue being open, so maybe the remaining check is a problematic false positive.

[morehouse]

@kcc: Do we plan to fix this in the near future?

[kcc]

nope.

[cbezault]

Hooking RtlRestoreContext and inspecting the _EXCEPTION_RECORD for Rsp/Esp could work on Windows.