[llvm-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

[Kostya Serebryany via llvm-dev]

On Mon, Jul 31, 2017 at 4:45 PM, Hans Wennborg <hans at chromium.org> wrote:

> On Mon, Jul 31, 2017 at 11:13 AM, Dimitry Andric <dimitry at andric.com>
> wrote:
> > On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote:
> >>
> >> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com>
> wrote:
> >>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <
> cfe-dev at 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?
>
> Kostya, does this ring any bells for you?
>

Nope, sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170731/4bba438f/attachment.html>