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

Adhemerval Zanella via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 25 04:56:19 PDT 2018

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 SANITIZERLINUX && 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?

More information about the llvm-dev mailing list