Bug 1126545

gcc in RHEL 7.0 supports -fsanitize=address or -fsanitize=thread, no idea about CentOS.  Those two options are mutually exclusive, you can use just one of them, not both, and need to have libasan and/or libtsan packages installed.

$ gcc -v; cat /tmp/a.c; gcc -fsanitize=address -o /tmp/a /tmp/a.c; /tmp/a; echo $?; gcc -fsanitize=thread -pie -fpie -o /tmp/a2 /tmp/a.c; /tmp/a2; echo $?; rpm -q gcc libasan libtsan
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) 
void
foo (char *p)
{
  p[8] = 1;
}

int
main ()
{
  char buf[8];
  foo (buf);
  return 0;
}
=================================================================
==26603== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffeea0eb18 at pc 0x400748 bp 0x7fffeea0eac0 sp 0x7fffeea0eab0
WRITE of size 1 at 0x7fffeea0eb18 thread T0
    #0 0x400747 (/tmp/a+0x400747)
    #1 0x400793 (/tmp/a+0x400793)
    #2 0x7f8b9f447af4 (/usr/lib64/libc-2.17.so+0x21af4)
    #3 0x400638 (/tmp/a+0x400638)
Address 0x7fffeea0eb18 is located at offset 40 in frame <main> of T0's stack:
  This frame has 1 object(s):
    [32, 40) 'buf'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
Shadow bytes around the buggy address:
  0x10007dd39d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
=>0x10007dd39d60: f1 f1 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10007dd39d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007dd39db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==26603== ABORTING
1
0
gcc-4.8.2-16.el7.x86_64
libasan-4.8.2-16.el7.x86_64
libtsan-4.8.2-16.el7.x86_64

Can you run the same on your CentOS?

I can't speak to the CentOS packages, but the SL7 packages return (almost) identically to yours.  On SL I've some minor differences in the hex addresses.

I can't reproduce this on RHEL7.0 machine - this indeed looks CentOS specific.

I tested the command in Comment #3 on my RHEL-7 machine as well as CentOS-7. The output is almost identical in both cases. As in SL, the only difference was in the hex addresses.

As pointed out by Jakub in Comment #2, the two options cannot be used together. Doing so produces the following error:

gcc: error: -fsanitize=address is incompatible with -fsanitize=thread

on both RHEL-7 and CentOS-7.

(I see virtually no difference between the two OSes in that regard).

yes, -fsanitize=address works in the absence of -fsanitize=thread. the little program above gives what appears to a quick glance to be the same output.

thanks for straightening me out!

==6418== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff79639098 at pc 0x400748 bp 0x7fff79639040 sp 0x7fff79639030
WRITE of size 1 at 0x7fff79639098 thread T0
    #0 0x400747 (/home/fsmith/Desktop/tst+0x400747)
    #1 0x400793 (/home/fsmith/Desktop/tst+0x400793)
    #2 0x7f0717729af4 (/usr/lib64/libc-2.17.so+0x21af4)
    #3 0x400638 (/home/fsmith/Desktop/tst+0x400638)
Address 0x7fff79639098 is located at offset 40 in frame <main> of T0's stack:
  This frame has 1 object(s):
    [32, 40) 'buf'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
Shadow bytes around the buggy address:
  0x10006f2bf1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
=>0x10006f2bf210: f1 f1 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10006f2bf220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006f2bf260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==6418== ABORTING

Closing out then based on #c7.