<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 4:45 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jul 31, 2017 at 11:13 AM, Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br>
> On 31 Jul 2017, at 19:26, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br>
>><br>
>> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br>
>>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>><br>
>>>> 5.0.0-rc1 has just been tagged.<br>
>>>><br>
>>>> Please build, test and upload binaries to the sftp. Let me know if<br>
>>>> there are any issues.<br>
>>><br>
>>> Built and tested rc1.  Test failures on amd64-freebsd10:<br>
>>><br>
>>> FAIL: LLVM-Unit :: ExecutionEngine/Orc/./<wbr>OrcJITTests/DummyRPC.<wbr>TestClearHandlers (1346 of 38616)<br>
>>> FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/<wbr>AddressSanitizer.<wbr>DoubleFreeTest (2480 of 38616)<br>
>>> FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/<wbr>AddressSanitizer.<wbr>ReallocFreedPointerTest (2505 of 38616)<br>
>>> FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/<wbr>AddressSanitizer.<wbr>UseThenFreeThenUseTest (2542 of 38616)<br>
>>> FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/<wbr>AddressSanitizer.WrongFreeTest (2546 of 38616)<br>
> ...<br>
>> Do we know what's up with all of these ASan failures? Is there a bug for it?<br>
><br>
> 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:<br>
><br>
> ==11122==AddressSanitizer CHECK failed: /usr/src/contrib/compiler-rt/<wbr>lib/asan/asan_poisoning.cc:36 "((AddrIsAlignedByGranularity(<wbr>addr))) != (0)" (0x0, 0x0)<br>
>     #0 0x806f163 in __asan::AsanCheckFailed(char const*, int, char const, unsigned long long, unsigned long long) (/share/dim/src/misc/hw+<wbr>0x806f163)<br>
>     #1 0x805dce3 in __sanitizer::CheckFailed(char const*, int, char const, unsigned long long, unsigned long long) (/share/dim/src/misc/hw+<wbr>0x805dce3)<br>
>     #2 0x80dfc65 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned char) (/share/dim/src/misc/hw+<wbr>0x80dfc65)<br>
>     #3 0x80696dd in __asan::AsanThread::Init(void) (/share/dim/src/misc/hw+<wbr>0x80696dd)<br>
>     #4 0x806997f in __asan::AsanThread::<wbr>ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*<wbr>) (/share/dim/src/misc/hw+<wbr>0x806997f)<br>
>     #5 0x806ecf3 in __asan::AsanInitInternal(void) (/share/dim/src/misc/hw+<wbr>0x806ecf3)<br>
>     #6 0x8092785 in clock_gettime (/share/dim/src/misc/hw+<wbr>0x8092785)<br>
><br>
> 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:<br>
><br>
> DBG: addr=0x284429f4, granularity=8<br>
><br>
> Tracing back the definitions, I found:<br>
><br>
> #define SHADOW_GRANULARITY (1ULL << SHADOW_SCALE)<br>
><br>
> then:<br>
><br>
> #define SHADOW_SCALE kDefaultShadowScale<br>
><br>
><br>
> then:<br>
><br>
> static const u64 kDefaultShadowScale = 3;<br>
><br>
> So this seems to be hardcoded.  There is a similar declaration in llvm's lib/Transforms/<wbr>Instrumentation/<wbr>AddressSanitizer.cpp.<br>
><br>
> 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.<br>
><br>
> Does anybody know whether the shadow granularity was different at some point?<br>
<br>
</div></div>Kostya, does this ring any bells for you?<br></blockquote><div><br></div><div>Nope, sorry. </div><div> </div></div><br></div></div>