similar to: [LLVMdev] should asan catch tihs?

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); > } >

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 11/3/12 4:06 AM, Kostya Serebryany wrote: > 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

Hello, I am building sanitizers for our different platforms and trying to use it in an example program, but while it seems like ASAN is running it's init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it never catches anything in the program. This is LLVM 8.0.1 btw. I was using this small test case: int main(int argc, char** argv) { int *array = new int[100]; delete []

Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote:

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

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?

Kostya Serebryany wrote: > I don't know anything about haskell, but if you post a minimal reproducer > here > we *may* be able to help. Its just so happens that I do have something here: https://github.com/erikd-ambiata/haskell-sanitize The Readme should have all the information you need. Any problems, please let mw know. Cheers, Erik --

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

Hello everybody, after moving from OS X to Linux build llvm with asan enabled (I also updated to trunk, but not sure if that's related). However, it's totally possible that I missed a step that I took back when I set this up for me, so I might be doing something very stupid. Anyway, I'm configuring LLVM with ../configure --prefix=/home/kfischer/julia/usr --build=x86_64-pc-linux-gnu

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 &&

What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/

On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <kcc at google.com> wrote: > 2 questions: > - Do you see this with the fresh llvm trunk? > - Can you prepare a minimized example? Pretty recent, I updated a couple days ago. I tried to minimize the attached but at the same time I didn't want to lose too many unions and casts in case it didn't trigger any more. $ clang

Indeed, removing that flag works fine, the only question is why this is added in tools/llvm-shlib/Makefile in the first place then and what to do about it: ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD)) # Don't allow unresolved symbols. LLVMLibsOptions += -Wl,--no-undefined endif On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <glider at

On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <kfischer at csail.mit.edu> wrote: > Hello everybody, > > after moving from OS X to Linux build llvm with asan enabled Sorry, I failed to parse this. You're compiling Clang on Linux, and OSX is unrelated, right? > (I also updated > to trunk, but not sure if that's related). However, it's totally possible > that I

Hi all, I have haskell code that calls into C code and i'd like to compile the C code with ASAN. I've managed to convince the build system to compile the C code with '-fsanitize=address -g' (so that if I get a link errors of the ASAN library isn't linked) and then also managed to link libasan, but when my trivial test program with an obvious out-of-bounds access run, I

+ more asan folks, please CC them to the code reviews. Also please make sure llvm-commits is CC-ed (cfe-commits for clang changes) On Tue, Oct 31, 2017 at 2:29 PM, Walter Lee <waltl at google.com> wrote: > I've prepared a preliminary set of patches that makes ASan work with > 32-byte shadow granularity, and I would like to get some feedback on > those patches as well as my

Specifically, the test is causing a link to occur for CGO stuff. It has been running 8 minutes now with Gold, and is producing a 400mb .o file afaict: % du -hs /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o 397M /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o What am I doing wrong here? -------------- next part -------------- An

Actually it only link the shlib fine. Linking any executable against it fails: llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols) /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++ -fsanitize=address -O3 -Wl,-R -Wl,'$ORIGIN/../lib' -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib

+Alexey On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> wrote: > > 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