You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a wild free, ASan usually crashes in random parts of the allocator. Ex.:
#0 0xb69c44ff in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) lib/sanitizer_common/sanitizer_atomic_clang.h:81
#1 0xb69c44ff in __asan::Allocator::AtomicallySetQuarantineFlag(__asan::AsanChunk*, void*, __sanitizer::BufferedStackTrace*) [asan_rtl]
#2 0xb69c44ff in __asan::Allocator::Deallocate(void*, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) [asan_rtl]
#3 0xb69c44ff in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) [asan_rtl]
We can do slighly better.
* For the small allocator, we always know the valid mapped range for the size class. A fast check.
* For the large allocator, we can touch a byte in the memory region that is being freed, crash, and detect this situation in the SEGV handler either by looking at the crashing code address, or by setting a global (thread-local) flag immediately before touching memory and clearing it immediately after.
Original issue reported on code.google.com by euge...@google.com on 17 Jul 2015 at 5:03
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
euge...@google.com
on 17 Jul 2015 at 5:03The text was updated successfully, but these errors were encountered: