LD_PRELOAD is needed to put asan runtime library closer to the start of symbol lookup order. On Android, symbol lookup is done depth-first, which mean that if there is an LD_PRELOAD-ed library that depends on libc, then libc would be ahead of libasan_preload.so, which would effectively disable all ASan interceptors. The same would happen if libasan_preload.so is not the first dependency of the main executable (can verify that with readelf -d | grep NEEDED).
It seems your fix is not 100% correct, after all. Could you send us contents of /proc/$PID/maps for an ASan process? What's your android version? On Mon, Jul 28, 2014 at 2:04 PM, ji wang <[email protected]> wrote: >>> Do we have to use LD_PRELOAD to preload this asan run-time Dso to the >> >process before this Asan instrumented executable run?And why? >> >I've tried not preload the asan run-time at first, and I got the > >>Please give more context: where did you try that and what exactly did you >> do. > > I am using Asan DSO enabled GCC4.9 android toolchain to test one shared lib > on android platform. And only this lib recompiled with Asan. > > When I loaded this recompiled lib and got "AddressSanitizer: failed to > intercept 'memcpy'" error, LD_PRELOAD can fix it but I don't want > use it because in some situation I really don't know where to place this > LD_PRELOAD thing and even I know the place still a litte diffcult to use it. > So I modified the code like I post in my last reply. > And now I want to know do we have to use LD_PRELOAD to preload the asan DSO? > so the same on android,arm,X86 platform? and why? and does my modification > have any side effect? > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
