libMesh/libmesh — pull request #395 by jwpeterson (2014-10-28 22:40:21+00:00)
Title: Add ability to turn on address sanitizer flags and associated configure tests

This branch adds the configure flag
```
--enable-sanitize="opt dbg"
```
for turning on the address sanitizer capability in the requested methods for compilers which support it. Currently GCC >= 4.8 and hand-built clang > 3.5 support this feature, the branch contains a configure test for dynamically determining support on any compiler. Similarly to valgrind, address sanitizer can catch memory errors, but only slows your code down by a factor of about 2x.

The output from address sanitizer for this simple program which writes past the end of an array:
```
int main()
{
int *array = new int[100];
delete [] array;
return array[1]; // BOOM
}
```

is:
```
=================================================================
==40035== ERROR: AddressSanitizer: heap-use-after-free on address 0x602e0001fc64 at pc 0x10c1d2f13 bp 0x7fff53a2d110 sp 0x7fff53a2d108
READ of size 4 at 0x602e0001fc64 thread T0
#0 0x10c1d2f12 (/Users/..././as+0x100000f12)
#1 0x7fff89e335fc (/usr/lib/system/libdyld.dylib+0x35fc)
#2 0x0
0x602e0001fc64 is located 4 bytes inside of 400-byte region [0x602e0001fc60,0x602e0001fdf0)
freed by thread T0 here:
#0 0x10c1e37aa (/opt/moose/gcc_4.8.3/lib/libasan.0.dylib+0xe7aa)
#1 0x10c1d2ee3 (/Users/..././as+0x100000ee3)
#2 0x7fff89e335fc (/usr/lib/system/libdyld.dylib+0x35fc)
#3 0x0
previously allocated by thread T0 here:
#0 0x10c1e35ea (/opt/moose/gcc_4.8.3/lib/libasan.0.dylib+0xe5ea)
#1 0x10c1d2ed3 (/Users/..././as+0x100000ed3)
#2 0x7fff89e335fc (/usr/lib/system/libdyld.dylib+0x35fc)
#3 0x0
Shadow bytes around the buggy address:
0x1c05c0003f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c05c0003f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c05c0003f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c05c0003f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c05c0003f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c05c0003f80: fa fa fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd
0x1c05c0003f90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x1c05c0003fa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x1c05c0003fb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa
0x1c05c0003fc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c05c0003fd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==40035== ABORTING
```

I'm hopting to get better at interpreting the output over time...

Issue #386.