[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 Evgeniy Stepanov changed: What|Removed |Added CC||eugeni.stepanov at gmail ||dot com --- Comment #7 from Evgeniy Stepanov 2013-02-19 20:35:12 UTC --- You've got a constructor of an uninstrumented shared library calling back into the application code. Of course, it happens before constructors of the main executable run. This breaks ASan initialization order. boost::get_static_exception_object is compiled in both hoge1.o and hoge2.o, both as weak symbols, one of them is ASan-instrumented. The call from a shared library constructor is resolved to the instrumented version from the main executable. This shows that bad things can happen implicitly, in very harmlessly looking code. We probably should not rely on normal constructors and switch .preinit_array. The only thing that is stronger than .preinit_array is DF_1_INITFIRST, we can't use it with static libasan, unfortunately.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #11 from Evgeniy Stepanov 2013-02-20 14:57:02 UTC --- Yes, dynamic libasan is still busted. We could link a small .o into executables built with dynamic libasan; that .o would contain a .preinit record pointing to the dynamically-linked __asan_init.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #13 from Evgeniy Stepanov 2013-02-20 18:29:57 UTC --- I don't see what can be done in that case. We should just declare it unsupported. We've got this problem on Android, where an instrumented JNI library is loaded into Dalvik VM, which is outside of user control. We "solve" it by requiring that the runtime library is LD_PRELOAD-ed into the DVM (Android has a mechanism to do this on an individual app basis on rooted devices).
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #16 from Evgeniy Stepanov 2013-02-21 11:51:17 UTC --- (In reply to comment #14) > (In reply to comment #13) > > We've got this problem on Android, where an instrumented JNI library is > > loaded > > into Dalvik VM, which is outside of user control. We "solve" it by requiring > > that the runtime library is LD_PRELOAD-ed into the DVM (Android has a > > mechanism > > to do this on an individual app basis on rooted devices). > > OT, but what is this mechanism you speak of? Currently this bug is the top > google hit for "Dalvik sanitizer LD_PRELOAD", and I don't see how it might > work > if the VM only forks, not execs. https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/internal/os/ZygoteConnection.java See the code for applyInvokeWithSystemProperty(). Also, https://code.google.com/p/address-sanitizer/wiki/Android. Sorry, this page was outdated until just now.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #2 from Evgeniy Stepanov --- As discussed in a email thread on gcc-patches, we will probably move away from including kernel headers and just define all the types in our code.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #2 from Evgeniy Stepanov --- Weak symbols. Ouch. We should link with libasan with librt. In Clang, we add -lrt to the linker flags when we see -fsanitize=(address|thread|memory).
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #11 from Evgeniy Stepanov --- (In reply to Yury Gribov from comment #4) > (In reply to Andrew Pinski from comment #3) > > I think in newer versions of glibc, clock_gettime is in libc.so now too. > > I think Andrew is right - clock_gettime is in libc nowadays. Should we > wontfix this bug? A trivial WAR for users would be to add -lrt to cmdline. > > (In reply to Evgeniy Stepanov from comment #2) > > We should link with libasan with librt. In Clang, we add -lrt to the linker > > flags when we see -fsanitize=(address|thread|memory). > > Evgeniy, what about a warning in GetRealFunctionAddress if real symbol is > NULL? Warning sounds like a good idea.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #15 from Evgeniy Stepanov --- (In reply to Yury Gribov from comment #13) > (In reply to Evgeniy Stepanov from comment #11) > > (In reply to Yury Gribov from comment #4) > > > Evgeniy, what about a warning in GetRealFunctionAddress if real symbol is > > > NULL? > > > > Warning sounds like a good idea. > > Cool. Should I file an issue at > http://code.google.com/p/address-sanitizer/issues ? No need, I'm fixing it now.
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #8 from Evgeniy Stepanov --- I'm a little surprised we did not run into this on Android yet - we use the same LD_PRELOAD scheme there. Are you linking libasan with libpthread? This might go away as libpthread constructors call one of the ASan interceptors that does ENSURE_ASAN_INITED(). Arguably, all interceptors should do it. I think Kostya raises valid points, but still, adding attribute((constructor)) is reasonable.
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #10 from Evgeniy Stepanov --- We don't intercept signal() on Android, because there is a friendly crash handler installed by the OS, and we don't need to handle segv ourselves.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #17 from Evgeniy Stepanov --- (In reply to Yury Gribov from comment #16) > (In reply to Evgeniy Stepanov from comment #15) > > No need, I'm fixing it now. > > Sorry for bothering but is this in compiler-rt trunk yet? Sorry, I forgot to mention this. Should be done in r194372.
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #13 from Evgeniy Stepanov --- (In reply to Yury Gribov from comment #12) > (In reply to Evgeniy Stepanov from comment #8) > > ... one of the ASan interceptors > > that does ENSURE_ASAN_INITED(). > > Arguably, all interceptors should do it. > > Can we force all interceptors to do this? I think it would be a good thing to do. Some interceptors are special in that they are allowed during __asan_init (ex. memmove). Something like COMMON_INTERCEPTOR_ENTER in asan_interceptors.cc could probably be applied safely to all interceptors.
[Bug other/55981] New: std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 Bug #: 55981 Summary: std::atomic store is split in two smaller stores Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: eugeni.stepa...@gmail.com Created attachment 29166 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29166 miscompiled program Hi, in the attached program, std::atomic store is compiled as two 4-byte stores, becoming not atomic at all. This happens at -O2 and higher. To reproduce, # g++ -std=c++11 -O3 1.cc -lpthread -o 1 # ./1 10004 ^ this can also be 30002, both outcomes are invalid.
[Bug other/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #1 from Evgeniy Stepanov 2013-01-14 22:45:30 UTC --- Disassembly of the loop in ff() function: 4007c0: movl $0x2,0x2008de(%rip)# 6010a8 4007ca: movl $0x1,0x2008d8(%rip)# 6010ac 4007d4: sub$0x1,%eax 4007d7: mfence 4007da: movl $0x4,0x2008c4(%rip)# 6010a8 4007e4: movl $0x3,0x2008be(%rip)# 6010ac 4007ee: mfence 4007f1: jne4007c0 <_Z2ffv+0xb0> Does not look atomic. Has all the proper fences, though.
[Bug other/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #2 from Evgeniy Stepanov 2013-01-14 22:48:08 UTC --- Btw, the same happens if atomic is replaced with "volatile unsigned long y" - which does not violate the standard, but may be considered undesirable by some. I don't have a strong opinion about this.
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #3 from Evgeniy Stepanov 2013-01-18 11:57:07 UTC --- (In reply to comment #2) > See 1.9p8 of the C++11 standard, first bullet: > > "Access to volatile objects are evaluated strictly according to the rules of > the abstract machine." > > From what I can see, implementing a store to a volatile DImode location as two > consecutive SImode stores to adjacent locations violates this aspect of the > standard. Furthermore, to expand on your parenthesized statement above, gcc > might not operate reliably if the device drivers in the kernel it is running > on > have their 64-bit immediate stores broken into pairs of 32-bit immediate > stores. ;-) So, what are these "rules of the abstract machine", and why do they allow non-atomic store of a large volatile aggregate (it is definitely not atomic, right?), and require atomicity for volatile long?
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #5 from Evgeniy Stepanov 2013-01-18 16:38:11 UTC --- Well, it's true that classes have assignment operators, and basic types don't. But this does not have anything to do with how the assignment could (or could not) be implemented at the machine level. AFAIU, the main point here is that a valid, data-race-free program can't observe the non-atomicity of a 64-bit store. And there is no special clause for volatile stores in this regard, either. I agree that in practice volatile stores of reasonably-sized basic types must be atomic, or a lot of legacy code will break.
[Bug c++/80839] Memory leak in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80839 Evgeniy Stepanov changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com --- Comment #1 from Evgeniy Stepanov --- MemorySanitizer requires that all code in the program is instrumented, with the exception of libc, but not libstdc++/libc++. https://clang.llvm.org/docs/MemorySanitizer.html#handling-external-code
[Bug c++/80839] Memory leak in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80839 --- Comment #2 from Evgeniy Stepanov --- Hmm, where is the button to mark this resolved/wontfix?
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #15 from Evgeniy Stepanov --- In fact, a recent change disabled ASAN_FLEXIBLE_MAPPING_AND_OFFSET and killed all supporting code. Or are you talking about a different change? ASAN_FLEXIBLE_MAPPING_AND_OFFSET indeed prevents LD_PRELOAD with unsanitized binaries, and it was one of the reasons for killing it.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #20 from Evgeniy Stepanov --- I can confirm that the issue can be reproduced on 3.13.0-5-generic (ubuntu 14.04 candidate), and can not be reproduced on 3.11.0-15-generic (ubuntu 13.10).
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #21 from Evgeniy Stepanov ---
A reproducer without ASan:
#include
#include
#include
#include
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i < 100; ++i)
mmap(p + i * 4096, 4096, PROT_WRITE | PROT_READ, MAP_PRIVATE |
MAP_ANONYMOUS, 0, 0);
printf("PID %d\n", getpid());
sleep(100);
}
[Bug rtl-optimization/60456] New: Uninitialized read in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456 Bug ID: 60456 Summary: Uninitialized read in copy_rtx Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eugeni.stepanov at gmail dot com Created attachment 32301 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32301&action=edit proof ==26761== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f2c4996caa9 in copy_rtx(rtx_def*) build-msan/gcc/../../gcc/rtl.c:263:42 #1 0x7f2c49992513 in process_rtx(rtx_def*, int) build-msan/gcc/../../gcc/gensupport.c:535 #2 0x7f2c49992513 in rtx_handle_directive(int, char const*) build-msan/gcc/../../gcc/gensupport.c:2243 #3 0x7f2c499c4540 in handle_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:984 #4 0x7f2c499c39bd in handle_toplevel_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1010 #5 0x7f2c499c2176 in read_md_files(int, char**, bool (*)(char const*), void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1138 #6 0x7f2c4998a397 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) build-msan/gcc/../../gcc/gensupport.c:2504 #7 0x7f2c4996017c in main build-msan/gcc/../../gcc/genpreds.c:1369 Uninitialized value was created by a heap allocation #0 0x7f2c4990579d in malloc /code/llvm/build0/../projects/compiler-rt/lib/msan/msan_interceptors.cc:781 #1 0x7f2c499d4d80 in xmalloc build-msan/build-x86_64-unknown-linux-gnu/libiberty/../../../libiberty/xmalloc.c:147 #2 0x7f2c499878e9 in ggc_internal_alloc_stat(unsigned long) build-msan/gcc/../../gcc/ggc-none.c:46 #3 0x7f2c4996b469 in ggc_alloc_rtx_def_stat(unsigned long) build-msan/gcc/../../gcc/ggc.h:257 #4 0x7f2c4996afdc in rtx_alloc_stat(rtx_code) build-msan/gcc/../../gcc/rtl.c:195:12 #5 0x7f2c49980e84 in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1127 #6 0x7f2c49984c52 in read_nested_rtx() build-msan/gcc/../../gcc/read-rtl.c:1351 #7 0x7f2c499814fe in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1156 #8 0x7f2c49984c52 in read_nested_rtx() build-msan/gcc/../../gcc/read-rtl.c:1351 #9 0x7f2c49982c7b in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1190 #10 0x7f2c4997c44d in read_rtx(char const*, rtx_def**) build-msan/gcc/../../gcc/read-rtl.c:1084 #11 0x7f2c49991d39 in rtx_handle_directive(int, char const*) build-msan/gcc/../../gcc/gensupport.c:2241 #12 0x7f2c499c4540 in handle_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:984 #13 0x7f2c499c39bd in handle_toplevel_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1010 #14 0x7f2c499c2176 in read_md_files(int, char**, bool (*)(char const*), void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1138 #15 0x7f2c4998a397 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) build-msan/gcc/../../gcc/gensupport.c:2504 #16 0x7f2c4996017c in main build-msan/gcc/../../gcc/genpreds.c:1369 Uninitialized memory comes from this expression on line 263: ORIGINAL_REGNO (XEXP (orig, 0)) To verify, apply the attached patch, go the build directory and run ./gcc/build/genpreds -h ../gcc/config/i386/i386.md The patch fills malloc()-ed memory with a specific pattern and then finds that pattern at the line above.
[Bug rtl-optimization/60456] Uninitialized read in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456 Evgeniy Stepanov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Evgeniy Stepanov --- Yeah, that's it. I should run on trunk next time.
[Bug rtl-optimization/60508] New: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 Bug ID: 60508 Summary: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eugeni.stepanov at gmail dot com Created attachment 32339 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32339&action=edit source code At r208400, GCC is failing with internal compiler error on the attached source generated with csmith. $ gcc -O -S z.c -w z.c: In function ‘fn1’: z.c:33:1: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082 } ^ 0x8aa962 lra_set_insn_recog_data(rtx_def*) ../../gcc/lra.c:1080 0x8ab4cf lra_get_insn_recog_data ../../gcc/lra-int.h:464 0x8ab4cf lra_update_insn_regno_info ../../gcc/lra.c:1749 0x8ab4cf lra_update_insn_regno_info ../../gcc/lra.c:1740 0x8ab6b1 lra_push_insn_1 ../../gcc/lra.c:1802 0x8ab6b1 lra_push_insn(rtx_def*) ../../gcc/lra.c:1810 0x8ab89c push_insns ../../gcc/lra.c:1853 0x8abc65 lra_process_new_insns(rtx_def*, rtx_def*, rtx_def*, char const*) ../../gcc/lra.c:1898 0x8b9df6 curr_insn_transform ../../gcc/lra-constraints.c:3689 0x8bbb84 lra_constraints(bool) ../../gcc/lra-constraints.c:4157 0x8ac4d3 lra(_IO_FILE*) ../../gcc/lra.c:2340 0x86af0e do_reload ../../gcc/ira.c:5457 0x86af0e rest_of_handle_reload ../../gcc/ira.c:5598 0x86af0e execute ../../gcc/ira.c:5627
[Bug sanitizer/61771] Regressions in ASan testsuite on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 --- Comment #3 from Evgeniy Stepanov --- Yes, FP on ARM is non-standard and differs in GCC and Clang implementations. Disabling fast unwind is not really an option, as you are looking at 10x, maybe 100x slowdown (depending of the app, of course). It should be possible to detect fp layout on the frame basis - there is a slot (don't know which one off the top of my head) that is FP in one compiler and return address in the other. Comparing its contents with the current stack limits (readily available in ASan) should do the trick. Of course, it would be awesome if we could synchronize (and document somewhere) FP stack layout between GCC and Clang - after all, there is no strong reason to do it one way or the other.
[Bug middle-end/48076] New: Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
Summary: Unsafe double checked locking in __emutls_get_address
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eugeni.stepa...@gmail.com
The following piece of code around emutls.c:138 uses double checked locking to
initialize a tls offset to the next available value.
pointer offset = obj->loc.offset;
if (__builtin_expect (offset == 0, 0))
{
static __gthread_once_t once = __GTHREAD_ONCE_INIT;
__gthread_once (&once, emutls_init);
__gthread_mutex_lock (&emutls_mutex);
offset = obj->loc.offset;
if (offset == 0)
{
offset = ++emutls_size;
obj->loc.offset = offset;
}
__gthread_mutex_unlock (&emutls_mutex);
}
struct __emutls_array *arr = __gthread_getspecific (emutls_key);
This code needs more barriers to be correct. For example, it is entirely
possible for emutls_key value used in the last line of the code snippet to be
prefetched before obj->loc.offset is loaded, and, consequently, before
emutls_init is called. In short, there needs to be a happens-before
relationship between obj->loc.offset assignment and the unprotected read at the
first line.
This looks unlikely on x86, but it may be a much bigger deal on ARM.
This was detected with ThreadSanitizer
(http://code.google.com/p/data-race-test/wiki/ThreadSanitizer) on an Android
device.
==822== WARNING: Possible data race during read of size 4 at 0x44B74: {{{
==822==T14 (L{}):
==822== #0 0xB7E0: __emutls_get_address gcc/emutls.c:138
==822== #1 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #2 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822== Concurrent write(s) happened at (OR AFTER) these points:
==822==T12 (L{L312}):
==822== #0 0xB80C: __emutls_get_address gcc/emutls.c:145
==822== #1 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #2 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822== Address 0x44B74 is 8 bytes inside data symbol
"__emutls_v._ZN27NegativeTests_PerThreadTestL17per_thread_globalE"
==822== Locks involved in this report (reporting last lock sites): {L312}
==822==L312 (0x44C18)
==822== #0 0x80108084: pthread_mutex_lock
tsan/ts_valgrind_intercepts.c:934
==822== #1 0xB808: __emutls_get_address gcc/gthr-posix.h:768
==822== #2 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #3 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822==Race verifier data: 0xB7E0,0xB80C
==822== }}}
