[Bug sanitizer/80027] New: ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 Bug ID: 80027 Summary: ASAN breaks DT_RPATH $ORIGIN in dlopen() Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: michael.thayer at oracle dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 40957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40957&action=edit Preprocessed demonstration code When I build a small test programme with DT_RPATH $ORIGIN set and address sanitiser enabled, if fails to find a shared object "test.so" in the same folder as the binary. If I leave off "-fsanitize=address" (the preprocessor output produced is identical) it finds the library. gcc output below, preprocessor output attached. $ gcc -v --save-temps test.c -o test -ldl -Wl,-rpath,'$ORIGIN' -fsanitize=address Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-8ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170221 (Ubuntu 6.3.0-8ubuntu1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-fsanitize=address' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu test.c -mtune=generic -march=x86-64 -fsanitize=address -fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o test.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-fsanitize=address' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -fsanitize=address -fstack-protector-strong -Wformat -Wformat-security -o test.s GNU C11 (Ubuntu 6.3.0-8ubuntu1) version 6.3.0 20170221 (x86_64-linux-gnu) compiled by GNU C version 6.3.0 20170221, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15 warning: GMP header version 6.1.2 differs from library version 6.1.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (Ubuntu 6.3.0-8ubuntu1) version 6.3.0 20170221 (x86_64-linux-gnu) compiled by GNU C version 6.3.0 20170221, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15 warning: GMP header version 6.1.2 differs from library version 6.1.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: efffe3a8eab4a38b76a97676d9f27d34 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-fsanitize=address' '-mtune=generic' '-march=x86-64' as -v --64 -o test.o test.s GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.28 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/:
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 --- Comment #2 from Michael Thayer --- Adding -static-libasan to the build and link flags and linking to libasan.a (for some reason it is not always done automatically, but our build system is rather complex) produces a segmentation fault as below. Not sure if that should be reported or whether it is just me doing something wrong. I will probably have to rebuild libasan.a to get more information. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x56e0463a in __sanitizer::MaybeInstallSigaction(int, void (*)(int, void*, void*)) () #2 0x56e049d3 in __sanitizer::InstallDeadlySignalHandlers(void (*)(int, void*, void*)) () #3 0x56df18e8 in __asan::AsanInitInternal() () #4 0x77de8932 in _dl_init (main_map=0x77ffe168, argc=1, argv=0x7fffdd28, env=0x7fffdd38) at dl-init.c:105 #5 0x77dd8cda in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #6 0x0001 in ?? () #7 0x7fffe0d0 in ?? () #8 0x in ?? ()
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 --- Comment #3 from Michael Thayer --- Seems my mistake. I think the ASAN library was still getting loaded dynamically. Now I have the following problem, which I think means that code (constructors?) getting called before ASAN is initialised is getting hold of memory map areas which ASAN is hard-coded to use. So probably no static ASAN for me. ==10420==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==10420==ASan shadow was supposed to be located in the [0x7fff7000-0x10007fff7fff] range. ==10420==Process memory map follows: 0x7fff7000-0x8fff7000 0x8fff7000-0x02008fff7000 0x02008fff7000-0x10007fff8000 [...]
[Bug c/82792] New: Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 Bug ID: 82792 Summary: Fallthrough attribute ignored after label Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: michael.thayer at oracle dot com Target Milestone: --- Created attachment 42508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42508&action=edit Test case I have a test case, a simplified version of our actual code, where the fallthrough attribute is ignored when a label immediately precedes the default case label and a fallthrough warning is triggered. Please see attached test case and output. Simple work-arounds welcome too.
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #1 from Michael Thayer --- Created attachment 42509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42509&action=edit gcc -v -save-temps -c -Wextra -Werror -x c -o test.o test.c > gcc-out 2>&1
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #2 from Michael Thayer --- Created attachment 42510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42510&action=edit Preprocessor output (almost identical to source)
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #3 from Michael Thayer --- Created attachment 42511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42511&action=edit Assembly output
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #5 from Michael Thayer --- This works for the test case I provided above, but not for our original source. Attaching a new test case. This one is slightly more involved, as it requires both g++ and address sanitizer. Should I create a new bug for this?
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #6 from Michael Thayer --- Created attachment 42514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42514&action=edit New test case
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #7 from Michael Thayer --- Created attachment 42515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42515&action=edit g++ -v -save-temps -c -Wextra -Werror -fsanitize=address -o test.o test.cpp > gcc-out 2>&1
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #8 from Michael Thayer --- Created attachment 42516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42516&action=edit Preprocessor output (almost identical to source)
[Bug c/82792] Fallthrough attribute ignored after label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #9 from Michael Thayer --- Created attachment 42517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42517&action=edit Assembly output
[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 Michael Thayer changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org, ||marxin at gcc dot gnu.org Component|c |sanitizer Summary|Fallthrough attribute |Fallthrough attribute |ignored after label |ignored after label, and ||before with address ||sanitizer --- Comment #10 from Michael Thayer --- I was only able to work around this by disabling asan on that particular file.
[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 Michael Thayer changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #11 from Michael Thayer --- Setting this back to "unconfirmed" as it is still a problem with the attribute before the label.
