Created attachment 30975 [details] Repro I've found that Sanitizer will sometimes report a warning about failed interceptions of libc functions. $ ~/install/gcc-master/bin/gcc prog.c -fsanitize=address -DGEN_PLT $ LD_LIBRARY_PATH=~/install/gcc-master/lib64:$LD_LIBRARY_PATH ASAN_OPTIONS=verbosity=1 ./a.out ==30654== Parsed ASAN_OPTIONS: verbosity=1 ==30654== AddressSanitizer: failed to intercept 'memcpy' ==30654== AddressSanitizer: libc interceptors initialized ... After small and inspiring investigation I've found out that this warning is caused by check for successful interception of memcpy in libsanitizer/asan/asan_interceptors.cc:676: ASAN_INTERCEPT_FUNC(memcpy); Apart from other actions, this macro verifies that memcpy and __interceptor_memcpy resolve to the same address. Unfortunately this does not happen if main executable takes address of memcpy. In that case ld.so will resolve memcpy to the address of corresponding PLT entry in executable. This won't cause any problem (because PLT entry will eventually call Asan's memcpy) but will make libsanitizer think that it has failed to override memcpy. This problem could be worked around by compiling with -static-libasan because in this case memcpy will be resolved to __interceptor_memcpy at link time (i.e. statically). AFAIK Clang uses static libsanitizer by default so they probably never ever faced this problem. I suggest that we either remove the warning or make the check in ASAN_INTERCEPT_FUNC more sophisticated so as to support dynamic libsanitizer. -Y
In clang we indeed support *only* static run-time and have no experience with dynamic run-time on Linux. I wonder if this may affect Mac or Android, where the run-time is dynamic?
/* Answering from my personal account */ According to http://marc.info/?t=136458341500002 this may not be a problem for Android. It seems that NDK links shared libs with -Bsymbolic which should prevent interpositions like this. Haven't verified this though, no Android device at hand... -Y
Konstantin, What about returning true in interception_linux.cc #if defined(__pic__) && !defined(__ANDROID__)? I can cook a proper patch if this sounds reasonable. -Y
(In reply to Yury Gribov from comment #3) > Konstantin, > > What about returning true in interception_linux.cc #if defined(__pic__) && > !defined(__ANDROID__)? I can cook a proper patch if this sounds reasonable. > > -Y Yes, please send the patch upstream (http://llvm.org/docs/Phabricator.html). I am not sure how we will test it there though... Also, why does this warning bother you? Does it cause other visible and negative effects?
> Yes, please send the patch upstream Will do. > Also, why does this warning bother you? > Does it cause other visible and negative effects? No, it's really more of a cosmetic change. -Y
Why bother then?
Well, I think people will keep asking about these warnings and spend time debugging them. You don't like the platform-specific code?
I especially dislike changes which I can't test upstream
I see. The disagreement about static linking of libsanitizer in gcc/llvm is rather unfortunate. Well, you have the final call on this. BTW could someone try repro on Mac? I wonder if it has the same problem (and thus requires the same patch!). -Y
(In reply to Yury Gribov from comment #9) > I see. The disagreement about static linking of libsanitizer in gcc/llvm is > rather unfortunate. Well, you have the final call on this. You may use -static-libasan > > BTW could someone try repro on Mac? I wonder if it has the same problem (and > thus requires the same patch!). glider? > > -Y
(In reply to Kostya Serebryany from comment #10) > You may use -static-libasan Well, that's a universal solution. > glider? Sorry, I'm completely ignorant of Apple stuff :( -Y
This problem doesn't reproduce on OSX. - Glider (:
(Well, I've only tested this with Clang on OSX. No idea whether it works with GCC or not, but there should be no difference, since the dynamic runtime library is the same)
I hate zombie bugs. Can we either fix or wontfix this?
Rejected by Asan team.