On 31 Jul 2017, at 19:26, Hans Wennborg <h...@chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimi...@andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-...@lists.llvm.org> >> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries to the sftp. Let me know if >>> there are any issues. >> >> Built and tested rc1. Test failures on amd64-freebsd10: >> >> FAIL: LLVM-Unit :: >> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616) >> FAIL: AddressSanitizer-Unit :: >> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616) >> FAIL: AddressSanitizer-Unit :: >> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of >> 38616) >> FAIL: AddressSanitizer-Unit :: >> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of >> 38616) >> FAIL: AddressSanitizer-Unit :: >> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616) ... > Do we know what's up with all of these ASan failures? Is there a bug for it?
I spent a limited amount of debugging on it, but the common problem is that on
i386 (aka 32-bit x86) all programs compiled with -fsanitize=address now die
with:
==11122==AddressSanitizer CHECK failed:
/usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x806f163 in __asan::AsanCheckFailed(char const*, int, char const,
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x806f163)
#1 0x805dce3 in __sanitizer::CheckFailed(char const*, int, char const,
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x805dce3)
#2 0x80dfc65 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned
char) (/share/dim/src/misc/hw+0x80dfc65)
#3 0x80696dd in __asan::AsanThread::Init(void)
(/share/dim/src/misc/hw+0x80696dd)
#4 0x806997f in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*) (/share/dim/src/misc/hw+0x806997f)
#5 0x806ecf3 in __asan::AsanInitInternal(void)
(/share/dim/src/misc/hw+0x806ecf3)
#6 0x8092785 in clock_gettime (/share/dim/src/misc/hw+0x8092785)
When I put some printfs in there, it showed that the expected address
granularity is 8, but the address to be checked was aligned on 4 bytes:
DBG: addr=0x284429f4, granularity=8
Tracing back the definitions, I found:
#define SHADOW_GRANULARITY (1ULL << SHADOW_SCALE)
then:
#define SHADOW_SCALE kDefaultShadowScale
then:
static const u64 kDefaultShadowScale = 3;
So this seems to be hardcoded. There is a similar declaration in llvm's
lib/Transforms/Instrumentation/AddressSanitizer.cpp.
I know that it *did* work at some point in the past, but it got broken in
recent history. I will have to do some archeology to figure out what happened.
Does anybody know whether the shadow granularity was different at some point?
-Dimitry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
