sanitizer test case failures after OS update

I updated one of my powerpc64le llvm test systems to Fedora 25 and I started getting a whole bunch of sanitizer test case failures. I tried testing some earlier revisions on the new OS that had worked fine under the old but they generate the same errors now so it isn't any changes in llvm.

There are two different errors:

FATAL: ThreadSanitizer: unsupported VMA range
FATAL: Found 47 - Supported 44 and 46


FATAL: Code 0x00010eddf660 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'.

Obviously something changed when I updated the OS but I am not sure how to fix it. The compilation options didn't change and ASLR isn't disabled. I used the same gcc compiler to build llvm under the different OS releases.

The first full test after the OS update is here:

Any ideas? Thanks!

Here's the full output from one of the failures:

FAIL: MemorySanitizer-powerpc64le :: Linux/ (34091 of 34964)
******************** TEST 'MemorySanitizer-powerpc64le :: Linux/' FAILED ********************

Hi Bill:

Not sure if it was intentional, but the old builds set CC, CXX, and LD_LIBRARY_PATH explicitly, but the new ones don’t. Also, you seem to be linking against gcc 7.2 libs above, but building with gcc 6.4.1.


I tried some runs using different versions of gcc and the one I posted was from when I used gcc 7.2. The actual bot was using the system gcc 6.4.1 compiler and libraries and got the same sorts of failures:

FAIL: SanitizerCommon-msan-powerpc64le-Linux :: Linux/closedir.c (65 of 171)
******************** TEST 'SanitizerCommon-msan-powerpc64le-Linux :: Linux/closedir.c' FAILED ********************

This looks to be due to the new kernel using 47 bits for addressing
and the ppc specific ASAN code is only setup to handle 44 or 46.
Talking with Steve Munroe, he says there is some work (already done?)
to handle 48 and 49 bits as well. We'll need a change ASAN to
handle those extra bits. It would be nice if we could just detect
what the value is and use that, rather than having fixed specific
values we know about and handle.


Oops, I meant TSAN above, although ASAN has similar code and
restrictions IIRC.


Ok. Note that I also see these failures after an Ubuntu 16.04 kernel update.

Yes, it's the kernel. See