[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Phil Miller unmobile at gmail dot com changed: What|Removed |Added CC||unmobile at gmail dot com --- Comment #38 from Phil Miller unmobile at gmail dot com --- (In reply to Dmitry Vyukov from comment #34) I propose to close this as obsolete. Or does somebody see any actionable items here? Non-pie binaries are supported by tsan now. Non-aslr (0x5) are not. I have a definite real-world use case for ThreadSanitizer with ASLR disabled, which I would really like to see supported. I'm happy to help in testing or hacking, with pointers in the right direction. Potentially horrifying details: I work on a system for distributed-memory parallel programming called Charm++. One of the features of our system is an ability to migrate user-level threads across processes and hardware nodes. This lets us provide functionality like load balancing, communication optimization, and fault tolerance with low overhead and fine granularity. To do this 'nicely', without our users having to write huge amounts of very finicky serialization code, we implement a technique called 'isomalloc'. In isomalloc, each thread is allocated in a chunk of virtual address space that is unique across the entire distributed set of processes. Any memory allocations by that thread are served from this chunk. When we want to migrate a thread, we can just copy the allocated bits of that chunk, including its stack, from one process to another, and all the pointers within will remain valid. Isomalloc works best when we can assure it as large a range of common, unoccupied virtual address space as possible. Thus, it's much happier when ASLR is disabled. Our runtime system supports a shared-memory multi-threading mode that allows message passing by pointer within each process. Several libraries on top of the RTS also exploit shared memory to reduce memory footprint and/or improve performance. So, we and our users really benefit from being able to use ThreadSanitizer to help debug our code. For instance, you can see our tracking bug for issues in our code code that have been detected using tsan so far: https://charm.cs.illinois.edu/redmine/issues/535 Tie that all together, and we really want to see tsan working with non-ASLR. I've just tested the patch in https://bugzilla.kernel.org/show_bug.cgi?id=66721 against Linux 3.19-rc1, and found that it doesn't (no longer?) solve this issue. I tried compiling my code as non-PIE to hack around this issue. GCC will accept -fsanitize=thread -fPIC -shared instead of -fsanitize=thread -fPIE -pie to compile and link successfully. However, any attempts to run the resulting binary result in a segfault. Per earlier requests, here's /proc/.../maps for that process: 4000-5000 r-xp 08:07 2072846 /home/phil/pie 55754000-55755000 rw-p 08:07 2072846 /home/phil/pie 77ffb000-77ffd000 r-xp 00:00 0 [vdso] 77ffd000-77fff000 r--p 00:00 0 [vvar] 7ffde000-7000 rw-p 00:00 0 [stack] ff60-ff601000 r-xp 00:00 0 [vsyscall] If there's some other way to build as non-PIE that will let tsan work with ASLR disabled, I'm happy to get a workaround, as long as it's something I can document for our users.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #39 from Dmitry Vyukov dvyukov at google dot com --- Isomalloc works best when we can assure it as large a range of common, unoccupied virtual address space as possible. Thus, it's much happier when ASLR is disabled. I do not follow you here. How does ASLR give you larger continuous region? ASLR maps libraries in the middle of virtual address space (0x), so if anything it gives smaller continuous region. On top of that tsan itself uses lots of memory and restricts user mappings to 0x7e00-0x7 range. I would like to understand problem better before we do anything.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #40 from Dmitry Vyukov dvyukov at google dot com --- Phil, please move the discussion to: https://groups.google.com/forum/#!forum/thread-sanitizer This is not gcc specific, and more people will be able to see it in the tsan group.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #34 from Dmitry Vyukov dvyukov at google dot com --- I propose to close this as obsolete. Or does somebody see any actionable items here? Non-pie binaries are supported by tsan now. Non-aslr (0x5) are not.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #35 from H.J. Lu hjl.tools at gmail dot com --- Binutils 2.25 will mark PIE with non-zero load address as executable so that any kernel will load it at specified address.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #36 from Kostya Serebryany kcc at gcc dot gnu.org --- While we are at it, H.J., is there any hope with https://bugzilla.kernel.org/show_bug.cgi?id=66721 ?
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #37 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Kostya Serebryany from comment #36) While we are at it, H.J., is there any hope with https://bugzilla.kernel.org/show_bug.cgi?id=66721 ? I will see what I can do.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #32 from Yury Gribov y.gribov at samsung dot com --- Jakub has posted patch which may fix this: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg02044.html
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Jan 31 21:25:23 2014 New Revision: 207371 URL: http://gcc.gnu.org/viewcvs?rev=207371root=gccview=rev Log: PR sanitizer/59410 * lib/tsan-dg.exp (tsan_init): Instead of not running any tsan tests if trivial testcase doesn't run, set dg-do-what-default to compile. (tsan_finish): Restore dg-do-what-default. * g++.dg/tsan/atomic_free.C: Remove dg-do line. * g++.dg/tsan/fd_close_norace2.C: Likewise. * g++.dg/tsan/default_options.C: Likewise. * g++.dg/tsan/aligned_vs_unaligned_race.C: Likewise. * g++.dg/tsan/atomic_free2.C: Likewise. * g++.dg/tsan/cond_race.C: Likewise. * g++.dg/tsan/fd_close_norace.C: Likewise. * g++.dg/tsan/benign_race.C: Likewise. * c-c++-common/tsan/fd_pipe_race.c: Likewise. * c-c++-common/tsan/simple_race.c: Likewise. * c-c++-common/tsan/mutexset1.c: Likewise. * c-c++-common/tsan/thread_leak2.c: Likewise. * c-c++-common/tsan/tls_race.c: Likewise. * c-c++-common/tsan/write_in_reader_lock.c: Likewise. * c-c++-common/tsan/race_on_barrier2.c: Likewise. * c-c++-common/tsan/free_race2.c: Likewise. * c-c++-common/tsan/thread_leak.c: Likewise. * c-c++-common/tsan/thread_leak1.c: Likewise. * c-c++-common/tsan/race_on_barrier.c: Likewise. * c-c++-common/tsan/free_race.c: Likewise. * c-c++-common/tsan/sleep_sync.c: Likewise. * c-c++-common/tsan/tiny_race.c: Likewise. * c-c++-common/tsan/race_on_mutex2.c: Likewise. * c-c++-common/tsan/atomic_stack.c: Likewise. * c-c++-common/tsan/race_on_mutex.c: Likewise. Adjust line numbers in dg-output regexps. * c-c++-common/tsan/simple_stack.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/tsan/atomic_stack.c trunk/gcc/testsuite/c-c++-common/tsan/fd_pipe_race.c trunk/gcc/testsuite/c-c++-common/tsan/free_race.c trunk/gcc/testsuite/c-c++-common/tsan/free_race2.c trunk/gcc/testsuite/c-c++-common/tsan/mutexset1.c trunk/gcc/testsuite/c-c++-common/tsan/race_on_barrier.c trunk/gcc/testsuite/c-c++-common/tsan/race_on_barrier2.c trunk/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c trunk/gcc/testsuite/c-c++-common/tsan/race_on_mutex2.c trunk/gcc/testsuite/c-c++-common/tsan/simple_race.c trunk/gcc/testsuite/c-c++-common/tsan/simple_stack.c trunk/gcc/testsuite/c-c++-common/tsan/sleep_sync.c trunk/gcc/testsuite/c-c++-common/tsan/thread_leak.c trunk/gcc/testsuite/c-c++-common/tsan/thread_leak1.c trunk/gcc/testsuite/c-c++-common/tsan/thread_leak2.c trunk/gcc/testsuite/c-c++-common/tsan/tiny_race.c trunk/gcc/testsuite/c-c++-common/tsan/tls_race.c trunk/gcc/testsuite/c-c++-common/tsan/write_in_reader_lock.c trunk/gcc/testsuite/g++.dg/tsan/aligned_vs_unaligned_race.C trunk/gcc/testsuite/g++.dg/tsan/atomic_free.C trunk/gcc/testsuite/g++.dg/tsan/atomic_free2.C trunk/gcc/testsuite/g++.dg/tsan/benign_race.C trunk/gcc/testsuite/g++.dg/tsan/cond_race.C trunk/gcc/testsuite/g++.dg/tsan/default_options.C trunk/gcc/testsuite/g++.dg/tsan/fd_close_norace.C trunk/gcc/testsuite/g++.dg/tsan/fd_close_norace2.C trunk/gcc/testsuite/lib/tsan-dg.exp
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #31 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #29) It is not that easy. gold before February 2013 doesn't grok -Ttext-segment, you need -Ttext there instead. See http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00777.html And, given that gcc can be configured to dynamically decide which of the linkers to use, it is a portability nightmare. So IMNSHO it is much better to improve libtsan to handle it correctly. We can pass -fuse-ld=bfd to gcc driver if it is supported and -fuse-ld=gold doesn't take -Ttext-segment.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #27 from Yury Gribov y.gribov at samsung dot com --- (In reply to Jakub Jelinek from comment #1) BTW, the tsan.exp tests don't seem to be as cheap as was claimed during the patch submission I guess this may depend on the machine, Max's is rather powerful. I'd prefer to at least throttle the torture options down to say -O0 and -O2 rather than so many different variants Agreed, we'll send a fix tomorrow.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #28 from Yury Gribov y.gribov at samsung dot com --- (In reply to H.J. Lu from comment #26) TSAN tests should specify a load address which works with TSAN. We'll add `-Wl,-Ttext-segment,0x8500' to TSan tests compilation options then.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org --- It is not that easy. gold before February 2013 doesn't grok -Ttext-segment, you need -Ttext there instead. See http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00777.html And, given that gcc can be configured to dynamically decide which of the linkers to use, it is a portability nightmare. So IMNSHO it is much better to improve libtsan to handle it correctly.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #30 from Kostya Serebryany kcc at gcc dot gnu.org --- We could add -Ttext-segment=0x7d00 (not 0x8500!), to either the tests or the driver, but a) see Jakub's comment about Gold b) it will not fix anything, and c) it will not help when ASLR is off.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org --- https://bugzilla.kernel.org/show_bug.cgi?id=66721 Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS. Any chance? Is there anything else we could do with this tsan issue? (given that this is our FAQ entry #1)
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #26 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Kostya Serebryany from comment #25) https://bugzilla.kernel.org/show_bug.cgi?id=66721 Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS. Any chance? Is there anything else we could do with this tsan issue? (given that this is our FAQ entry #1) TSAN tests shouldn't depend on kernel to load PIE at a suitable address at random since kernel may load PIE at the wrong address. TSAN tests should specify a load address which works with TSAN.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-06 Summary|Some tsan tests fail with |tsan tests fail with |address randomization |address randomization |disabled|disabled Ever confirmed|0 |1
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #19 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #18) (In reply to Kostya Serebryany from comment #16) Kernel is free to load PIE at ANY address it wants. But you can specify where to load PIE via a linker switch -Ttext-segment 0x8500 to tell kernel to load PIE to a specific address. Hm. Interesting. What do I do wrong? % clang++ simple_race.cc -fsanitize=thread -Wl,-Ttext-segment=0x7d00 ; (setarch x86_64 -R ./a.out ) FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x4000 0x7cf0) FATAL: Make sure to compile with -fPIE and to link with -pie. Please show the output of # readelf -lW a.out Your address must be sensible. Otherwise kernel will ignore it. Please try -Ttext-segment 0x8500.
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #20 from Kostya Serebryany kcc at gcc dot gnu.org ---
# readelf -lW a.out
Your address must be sensible. Otherwise kernel will ignore it.
Please try -Ttext-segment 0x8500.
How is 0x8500 censible if it's beyond the address space?
(Or I miss something?)
Anyway, here is an experiment that proves that on my box
-Ttext-segment is ignored if ASLR is off.
% cat print_main.cc
#include stdio.h
int main() {
printf(main: %p\n, main);
}
% g++ print_main.cc -fPIE -pie -Wl,-Ttext-segment=0x6ABC5500 ./a.out
main: 0x6abc5500072c
% g++ print_main.cc -fPIE -pie -Wl,-Ttext-segment=0x6ABC5500 setarch
x86_64 -R ./a.out
main: 0x472c
% readelf -lW ./a.out
Elf file type is DYN (Shared object file)
Entry point 0x6abc55000630
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
PHDR 0x40 0x6abc5540 0x6abc5540 0x0001f8
0x0001f8 R E 0x8
INTERP 0x000238 0x6abc55000238 0x6abc55000238 0x1c
0x1c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x00 0x6abc5500 0x6abc5500 0x00091c
0x00091c R E 0x20
LOAD 0x000e00 0x6abc55200e00 0x6abc55200e00 0x000228
0x000238 RW 0x20
DYNAMIC0x000e28 0x6abc55200e28 0x6abc55200e28 0x000190
0x000190 RW 0x8
NOTE 0x000254 0x6abc55000254 0x6abc55000254 0x44
0x44 R 0x4
GNU_EH_FRAME 0x000848 0x6abc55000848 0x6abc55000848 0x2c
0x2c R 0x4
GNU_STACK 0x00 0x 0x 0x00
0x00 RW 0x8
GNU_RELRO 0x000e00 0x6abc55200e00 0x6abc55200e00 0x000200
0x000200 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .dynamic .got
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #21 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Kostya Serebryany from comment #20) # readelf -lW a.out Your address must be sensible. Otherwise kernel will ignore it. Please try -Ttext-segment 0x8500. How is 0x8500 censible if it's beyond the address space? (Or I miss something?) Anyway, here is an experiment that proves that on my box -Ttext-segment is ignored if ASLR is off. That is true. The kernel change was made to fix: https://bugzilla.kernel.org/show_bug.cgi?id=36372
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #22 from Kostya Serebryany kcc at gcc dot gnu.org --- That is true. The kernel change was made to fix: https://bugzilla.kernel.org/show_bug.cgi?id=36372 Could you please explain the situation? What was fixed and in which kernel?
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com --- I opened: https://bugzilla.kernel.org/show_bug.cgi?id=66721
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #24 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Kostya Serebryany from comment #22) That is true. The kernel change was made to fix: https://bugzilla.kernel.org/show_bug.cgi?id=36372 Could you please explain the situation? What was fixed and in which kernel? The kernel bug is explained at https://bugzilla.redhat.com/show_bug.cgi?id=708563 https://bugzilla.kernel.org/show_bug.cgi?id=36372
