Ubuntu 13.04 compilation, installation, and upgrade GCC 4.9.0 address Sanitizer

@ Note:

Recently, I checked the crash of an online project. The review code is fruitless and the probability of crash is low. It cannot be reproduced in a local environment. After that, several servers running valgrind online won't crash. My personal guess may be that after valgrind is run, the performance is seriously degraded, causing the crash point to fail to be triggered.

GCC has supported address sanitizer since 4.8 and is also easy to use. This article will analyze the usage at the end of the article.

In addition, my environment is ubuntu13.04 + gcc4.7.3 with the goal of upgrading to 4.9.0.

@ Compile gcc4.9.0

$cd /tmp$wget ftp://mirrors.kernel.org/gnu/gcc/gcc-4.9.0/gcc-4.9.0.tar.gz$tar zxvf gcc-4.9.0.tar.gz$cd gcc-4.9.0$./contrib/download_prerequisites$cd ..$mkdir gcc-build-4.9.0$cd gcc-build-4.9.0$../gcc-4.9.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib$make -j4$make install$gcc -v

Supplement: The libraries compiled here are in the path/usr/local/lib64.

@ Usage

#include <stdio.h>                                                                                int main()                                                                      {                                                                                   int *p = new int;                                                               delete p;                                                                       *p = 10;                                                                        return 0;                                                                   }

This is a program for accessing the wild pointer, but it does not run coredump after being compiled with GCC (no matter whether-G is added. With address sanitize, we can do this.

$g++ test.cc -fsanitize=address -g$export LD_LIBRARY_PATH=/usr/local/lib64/$./a.out

I picked some running information and pasted it out.

==25380==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000eff0 at pc 0x4007d1 bp 0x7ffffbe70890 sp 0x7ffffbe70888WRITE of size 4 at 0x60200000eff0 thread T0    #0 0x4007d0 in main /home/parallels/sss/cc/test/test.cc:7    #1 0x7f6454635ea4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ea4)    #2 0x4006a8 (/home/parallels/sss/cc/test/a.out+0x4006a8)0x60200000eff0 is located 0 bytes inside of 4-byte region [0x60200000eff0,0x60200000eff4)freed by thread T0 here:    #0 0x7f645525a3e7 in operator delete(void*) ../../../../gcc-4.9.0/libsanitizer/asan/asan_new_delete.cc:81    #1 0x400799 in main /home/parallels/sss/cc/test/test.cc:6    #2 0x7f6454635ea4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ea4)previously allocated by thread T0 here:    #0 0x7f6455259f6f in operator new(unsigned long) ../../../../gcc-4.9.0/libsanitizer/asan/asan_new_delete.cc:50    #1 0x400789 in main /home/parallels/sss/cc/test/test.cc:5    #2 0x7f6454635ea4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ea4)

This information is clear enough.

@ Postscript

I have not tested its impact on performance yet. I hope it can help locate bugs after going online.