[llvm-dev] [compiler-rt][msan] msan tests failing on AArch64

[Adhemerval Zanella via llvm-dev]

On 24/10/2018 18:30, David Greene via llvm-dev wrote:
> Hi,
> 
> I'm getting the following running msan tests on one of our AArch64
> boxes:
> 
> FATAL: Code 0xaaacc3f5d4b0 is out of application range. Non-PIE build?
> FATAL: MemorySanitizer can not mmap the shadow memory.
> FATAL: Make sure to compile with -fPIE and to link with -pie.
> FATAL: Disabling ASLR is known to cause this error.
> FATAL: If running under GDB, try 'set disable-randomization off'.
> 
> ASLR is enabled.  The tests work on another AArch64 box so I don't think
> it's a problem with the test, per se.  msan.h indeed shows this address
> to be invalid:
> 
> #elif SANITIZER_LINUX && defined(__aarch64__)
> 
> // The mapping describes both 39-bits, 42-bits, and 48-bits VMA.  AArch64
> // maps:
> // - 0x0000000000000-0x0000010000000: 39/42/48-bits program own segments
> // - 0x0005500000000-0x0005600000000: 39-bits PIE program segments
> // - 0x0007f80000000-0x0007fffffffff: 39-bits libraries segments
> // - 0x002aa00000000-0x002ab00000000: 42-bits PIE program segments
> // - 0x003ff00000000-0x003ffffffffff: 42-bits libraries segments
> // - 0x0aaaaa0000000-0x0aaab00000000: 48-bits PIE program segments
> // - 0xffff000000000-0x1000000000000: 48-bits libraries segments
> // It is fragmented in multiples segments to increase the memory available
> // on 42-bits (12.21% of total VMA available for 42-bits and 13.28 for
> // 39 bits). The 48-bits segments only cover the usual PIE/default segments
> // plus some more segments (262144GB total, 0.39% total VMA).
> const MappingDesc kMemoryLayout[] = {
>     {0x00000000000ULL, 0x01000000000ULL, MappingDesc::INVALID, "invalid"},
> [...]
>     {0x0AAAAA0000000ULL, 0x0AAAB00000000ULL, MappingDesc::APP, "app-14"},
>     {0x0AAAB00000000ULL, 0x0AACAA0000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0AACAA0000000ULL, 0x0AACB00000000ULL, MappingDesc::SHADOW, "shadow-14"},
>     {0x0AACB00000000ULL, 0x0AADAA0000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0AADAA0000000ULL, 0x0AADB00000000ULL, MappingDesc::ORIGIN, "origin-14"},
>     {0x0AADB00000000ULL, 0x0FF9F00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FF9F00000000ULL, 0x0FFA000000000ULL, MappingDesc::SHADOW, "shadow-15"},
>     {0x0FFA000000000ULL, 0x0FFAF00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FFAF00000000ULL, 0x0FFB000000000ULL, MappingDesc::ORIGIN, "origin-15"},
>     {0x0FFB000000000ULL, 0x0FFFF00000000ULL, MappingDesc::INVALID, "invalid"},
>     {0x0FFFF00000000ULL, 0x1000000000000ULL, MappingDesc::APP, "app-15"},
> };
> 
> It looks like the address is in the invalid area between app-14 and
> shadow-14.  I remember I had a similar problem a few months ago and was
> pointed to a commit that fixed it.  When we updated to that commit, it
> fixed those tests.  But we're pretty up-to-date now and I am seeing
> these kinds of failures.
> 
> From what I can glean, I assume that an application that finds itself in
> an invalid area has a memory footprint that has grown beyond what msan
> expects.  Is that basically right?  If so, I don't understand why this
> would work on one AArch64 box and not another.  AFAIK the processors are
> the same.  The working one is SuSE 12.2 and the non-working one is SuSE
> 12.3.  I wonder if something about kernel differences between the two is
> causing this.  Memory ulimits are unlimited.  Anyone have ideas or
> things to try?

This seems to be printed by InitShadow and it is an initialization routine
which runs on all msan enabled binaries.  The only issue I think is runtime
is set __msan_track_origins by -msan-track-origins=1 option and unfortunately
it does not seem to be stressed in any testcase. Is it the case on this binary
you are testing?