Bug 1126545 - gcc was compiled without "-fsanitize" support
Summary: gcc was compiled without "-fsanitize" support
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gcc
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Jelinek
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-04 17:38 UTC by fred smith
Modified: 2014-08-07 06:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-07 06:33:15 UTC


Attachments (Terms of Use)

Description fred smith 2014-08-04 17:38:42 UTC
Description of problem:
attempting to compile C program using "-fsanitize=address" or "-fsanitize=thread" fails with error: 

cc: error: unrecognized command line option ‘-fsanitize=address -fsanitize=thread’

Version-Release number of selected component (if applicable):
gcc -v
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) 


How reproducible:
always

Steps to Reproduce:
1.try to compile any C program using those two -fsanitize=xxx options.
2.
3.

Actual results:


Expected results:
Can we get an official build of GCC in which those -fsanitize options are not disabled?

Additional info:
This occurs on Centos 7.0 using the stock GCC compiler.

Comment 2 Jakub Jelinek 2014-08-04 17:49:06 UTC
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.

Comment 3 Jakub Jelinek 2014-08-05 07:28:48 UTC
$ 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?

Comment 4 Pat Riehecky 2014-08-05 13:38:57 UTC
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.

Comment 5 Marek Polacek 2014-08-05 15:10:44 UTC
I can't reproduce this on RHEL7.0 machine - this indeed looks CentOS specific.

Comment 6 Akemi Yagi 2014-08-05 16:19:12 UTC
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).

Comment 7 fred smith 2014-08-07 03:02:02 UTC
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

Comment 8 Marek Polacek 2014-08-07 06:33:15 UTC
Closing out then based on #c7.


Note You need to log in before you can comment on or make changes to this bug.