Description of problem: [root@ibm-p8-01-lp4 ~]# cat t.c int main(int argc, char **argv) { return 0; } [root@ibm-p8-01-lp4 ~]# gcc -o t -fsanitize=address t.c [root@ibm-p8-01-lp4 ~]# ASAN_OPTIONS=verbosity=1 ./t ==28721== Parsed ASAN_OPTIONS: verbosity=1 ==28721== AddressSanitizer: libc interceptors initialized || `[0x040000000000, 0x0fffffffffff]` || HighMem || || `[0x028000000000, 0x03ffffffffff]` || HighShadow || || `[0x024000000000, 0x027fffffffff]` || ShadowGap || || `[0x020000000000, 0x023fffffffff]` || LowShadow || || `[0x000000000000, 0x01ffffffffff]` || LowMem || MemToShadow(shadow): 0x024000000000 0x0247ffffffff 0x025000000000 0x027fffffffff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 20000000000 ==28721== Installed the sigaction for signal 11 ==28721== AddressSanitizer CHECK failed: ../../../../libsanitizer/asan/asan_thread.cc:74 "((AddrIsInMem(stack_bottom_))) != (0)" (0x0, 0x0) ================================================================= ==28721== ERROR: AddressSanitizer: unknown-crash on address 0x3fffe93b49b0 at pc 0x3fffa875994c bp 0x3fffe93b34f0 sp 0x3fffe93b3560 WRITE of size 1392 at 0x3fffe93b49b0 thread T0 ==28721== AddressSanitizer: while reporting a bug found another one.Ignoring. Could it possibly be upstream issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 ? Version-Release number of selected component (if applicable): gcc-4.8.5-4.el7.ppc64 libasan-4.8.5-4.el7.ppc64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Let me look into this.
The following patch backported from trunk fixes the problem on my powerpc64 server: --- libsanitizer/asan/asan_rtl.cc.~0~ +++ libsanitizer/asan/asan_rtl.cc @@ -306,13 +306,15 @@ #if !ASAN_FIXED_MAPPING #if SANITIZER_WORDSIZE == 64 # if defined(__powerpc64__) - // FIXME: // On PowerPC64 we have two different address space layouts: 44- and 46-bit. - // We somehow need to figure our which one we are using now and choose + // We somehow need to figure out which one we are using now and choose // one of 0x00000fffffffffffUL and 0x00003fffffffffffUL. // Note that with 'ulimit -s unlimited' the stack is moved away from the top // of the address space, so simply checking the stack address is not enough. - kHighMemEnd = (1ULL << 44) - 1; // 0x00000fffffffffffUL + // This should (does) work for both PowerPC64 Endian modes. + // Similarly, aarch64 has multiple address space layouts: 39, 42 and 47-bit. + kHighMemEnd + = (1ULL << (MostSignificantSetBitIndex(GET_CURRENT_FRAME()) + 1)) - 1; # else kHighMemEnd = (1ULL << 47) - 1; // 0x00007fffffffffffUL; # endif The patch adjusts the memory mapping from the one shown in comment #0 to match GCC trunk: || `[0x0a0000000000, 0x3fffffffffff]` || HighMem || || `[0x034000000000, 0x09ffffffffff]` || HighShadow || || `[0x024000000000, 0x033fffffffff]` || ShadowGap || || `[0x020000000000, 0x023fffffffff]` || LowShadow || || `[0x000000000000, 0x01ffffffffff]` || LowMem || MemToShadow(shadow): 0x024000000000 0x0247ffffffff 0x026800000000 0x033fffffffff The patch also makes quite an improvement to the asan test results: +-- BASELINE | +-- PATCHED | | V V TEST 10 c-c++-common/asan/clone-test-1.c 8 c-c++-common/asan/global-overflow-1.c 8 c-c++-common/asan/heap-overflow-1.c 8 c-c++-common/asan/memcmp-1.c 8 5 c-c++-common/asan/null-deref-1.c 1 c-c++-common/asan/rlimit-mmap-test-1.c 8 c-c++-common/asan/sanity-check-pure-c-1.c 3 c-c++-common/asan/sleep-before-dying-1.c 8 c-c++-common/asan/stack-overflow-1.c 3 c-c++-common/asan/strip-path-prefix-1.c 8 c-c++-common/asan/strncpy-overflow-1.c 10 10 c-c++-common/asan/swapcontext-test-1.c 8 c-c++-common/asan/use-after-free-1.c 6 g++.dg/asan/deep-stack-uaf-1.C 8 g++.dg/asan/deep-tail-call-1.C 8 g++.dg/asan/deep-thread-stack-1.C 8 g++.dg/asan/default-options-1.C 8 g++.dg/asan/interception-failure-test-1.C 8 g++.dg/asan/interception-malloc-test-1.C 8 g++.dg/asan/interception-test-1.C 8 g++.dg/asan/large-func-test-1.C 8 g++.dg/asan/pr55617.C 3 g++.dg/asan/symbolize-callback-1.C
Thanks, that is all I need.
test fails with gcc-4.8.5-4.el7.ppc64 test passes for gcc-4.8.5-9.el7.ppc64 VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2433.html