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

[David Greene via llvm-dev]

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?

Thanks!

                            -David