similar to: [RFC] ASan: Reify all information relevant for diagnostics

Hi, I would like to improve the debugging experience for ASan. The idea is to have a couple of useful commands in LLDB (probably implemented as Python scripts) that could help the user when they are debugging an ASan-enabled binary. We already have some debugging API (asan_interface.h): // Print the description of addr (useful when debugging in gdb). void __asan_describe_address(void

Hi Manuel, I believe you're maintaining Phabricator at reviews.llvm.org <http://reviews.llvm.org/>. Duncan likes to send his patch comments via email, like in the example below. Do you know why don't his replies get imported into the web interface? The reply was sent to "reviews+D24569+public+a5763c0a090df06f at reviews.llvm.org

Kostya, all, I'm trying to build my project by clang 3.8rc1 with enabled asan (clang itself is address sanitized) and it fails on several files from my project (ISPC, https://github.com/ispc/ispc). I've reproduced this on MacOS and Linux. Please let me know if you need any other info. How to reproduce: 1) Build address sanitized clang 3.8rc1: cd /path-to-working-dir svn co

Why does compiler-rt ship a shared object for ASan on Android instead of a static library? Would statically linking ASan on Android at least be safe for standalone executables? And if I'm wanting to use ASan in C++ code that is invoked from an APK, can I statically link ASan? If not, what is the reason we need to preload Dalvik with the ASan shared object? I assume static linking here

+eugenis@ On Sat, Sep 21, 2013 at 4:58 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Why does compiler-rt ship a shared object for ASan on Android instead > of a static library? Would statically linking ASan on Android at > least be safe for standalone executables? > > And if I'm wanting to use ASan in C++ code that is invoked from an > APK, can I statically

My change 225282 broke an asan test [1], but by the time I got around to trying to revert it, I noticed that the test had started passing. Moreover, it seems to have been "fixed" by 225291 which at least does not seem related to the breakage directly. I'm puzzled now -- is the failing asan test flaky? Should I still revert 225282? Thank you for your time! [1]:

I just tried asan on an optimized 32 bit build of ------------------------------------- #include <stdint.h> __attribute__((noinline)) void f(uint64_t *p) { *p = 42; } int main() { void *p; f((uint64_t*)&p); } ------------------------------------ and it correctly catches the invalid access. If I comment the attribute, the optimizers find and exploit the undefined behavior and

Hi Kcc, I'm trying enabling the Asan in my firmware, but I find the asan instrumentation code size impact is too big for me. I just implement necessary firmware version runtime library functions (e.g. __asan_report_load8) with blank body firstly to pass the asan enabled build, but I find the new binary code size is already ~2.5 times as original one with asan disabled in GCC. I know Linux

If running ASan on the host architecture, we can symbolize output with: export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` ./myInstrumentedProgram but on Android symbolizing is more complex. The bash script below is a "hello world" for symbolizing ASan output on Android. Is there a simpler way to do this? # Execute the test and save its output adb push

I'm running debian jessie and added the nightly repos and installed clang-3.8. When trying to build with -fsanitize=address clang can't find an asan lib: /usr/bin/ld: cannot find /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory The apt page says the packages include compiler-rt which I thought included asan. Am I missing a package?

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

I've finished my initial set of patches to make 32-byte shadow granularity work on x86. Here is a summary of the changes from last week: - As discussed, I added a full redzone after every stack variable. - We discussed adding a -fsanitize-address-granularity=N flag, but I found the following existing flag has been sufficient for my purposes: -asan-mapping-scale N. If anyone thinks I

I'm getting this link failure when running ninja check on Linux. I'm configuring with shared libraries enabled, so I'm not sure why asan is looking for .a archives. $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON -DCLANG_INCLUDE_DOCS=ON -DBUILD_SHARED_LIBS=ON ../llvm $ ninja check-all FAILED: cd [..]bld/projects/compiler-rt/lib/asan/tests &&

From: http://address-sanitizer.googlecode.com/svn-history/r1624/wiki/Android.wiki > AddressSanitizer is fully supported in AOSP starting with JellyBean release. To run > applications built with ASan you'll need an -eng build of Android. > > To build any part of Android system with ASan, add > LOCAL_ADDRESS_SANITIZER:=true to the appropriate Android.mk. I don't see that

On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I just tried asan on an optimized 32 bit build of > ------------------------------------- > #include <stdint.h> > __attribute__((noinline)) > void f(uint64_t *p) { > *p = 42; > } > int main() { > void *p; > f((uint64_t*)&p); > } >

Hi Evgeniy, Now that I can run check-asan without the AArch64 tests, there are a number of ARM tests that fail with the wrong line number on the CHECK line... use-after-delete.cc:20:18: error: expected string not found in input // CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]] <stdin>:9:33: note: with expression "@LINE-10" equal to "10" #0

> Static runtime will only intercept calls from the main executable, but > not from any libraries. This may work for simple standalone programs, > but you may run into puzzling failures. What type of failures do you mean? Does the symbol mismatch break assumptions in the ASan runtime? It's easy to imagine, for example, ASan missing use-after-free bugs because the call to free() is

Also note that this is not the kind of bug for which asan is good. If we are dereferencing an uninitialized pointer, there is a high chance that the program will SEGV w/o any tool. If we are unlucky and the garbage is accidentally equal to some valid address, asan will not catch it either. Valgrind (and work-in-progress MemorySanitizer) will catch this. --kcc On Sat, Nov 3, 2012 at 5:38 AM, Eli

On Wed, Oct 30, 2013 at 2:08 PM, Greg Fitzgerald <garious at gmail.com> wrote: > If running ASan on the host architecture, we can symbolize output with: > > export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` > ./myInstrumentedProgram > > but on Android symbolizing is more complex. The bash script below is > a "hello world" for symbolizing ASan output

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer