[llvm-dev] [compiler-rt][msan] msan tests failing on AArch64 (original) (raw)

David Greene via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 24 14:30:57 PDT 2018

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

More information about the llvm-dev mailing list