codenote / address-sanitizer Goto Github PK

Please add the -C option to addr2line otherwise we get mangled names.  See 
http://sourceware.org/binutils/docs/binutils/addr2line.html.

What steps will reproduce the problem?
$ cat asan-exceptions-test.cc
#include <stdio.h>
#include <string>

class Action {
 public:
  Action() {}
  void PrintString(const std::string& msg) const {
    fprintf(stderr, "%s\n", msg.c_str());
  }
  void Throw(const char& arg) const {
    PrintString("PrintString called!"); // this line is important
    throw arg;
  }
};

int main() {
  const Action a;
  fprintf(stderr, "&a before = %p\n", &a);
  try {
    a.Throw('c');
  } catch (const char&) {
    fprintf(stderr, "&a in catch = %p\n", &a);
  }
  fprintf(stderr, "&a final = %p\n", &a);
  return 0;
}
$ ../my_clang++ -faddress-sanitizer -O2 asan-exceptions-test.cc 
$ ./a.out
&a before = 0x7fff1300e2c0
PrintString called!
&a in catch = 0x101010101010101
&a final = 0x101010101010101

Please use labels and text to provide additional information.

Generated binary incorrectly handles exceptions: the address of local "const 
Action a" is stored in a register (r14 or r15) which is assumed to be 
callee-safe, but which is overwritten when the exception is caught.

char * s = (char*)malloc(4096);
memset(s+4095, 0, 2);

Here Clang changes "memset 2 bytes" to a single "store i16" instruction, and we 
don't instrument (and fail on) access to the memory outside allocated array.

Currently, asan does not instrument thread-local globals, but it should. 

Two problems here: 

1. The address of main thread's thread-local is not available at the link time 
where we currently form the array which will be passed to 
__asan_register_globals

2. Need to poison the non-main-thread's copies somehow. 

Currently, we can no mix PIC and non-PIC objects if globals are instrumented


% head a.cc b.cc
==> a.cc <==
#include <stdio.h>
int* CCC = new int;

int *zoo() {
  printf("z1 %p\n", &CCC);
  return CCC;
}

==> b.cc <==
#include <stdio.h>

extern int *CCC;
extern int *zoo();

int main(int argc, char** argv) {
  printf("z2 %p\n", &CCC);
  zoo();
}


./my_clang++ -O2 a.cc -fasan -c -fPIC && gcc -shared a.o -o a.so && 
./my_clang++ -fasan -O2  b.cc a.so -Wl,-rpath=. && ./a.out 
z2 0x60e180
z1 0x7fc063fa2060

# both numbers should be the equal

What steps will reproduce the problem?
1. Compile with -faddress-sanitizer
2. Launch program

What is the expected output? What do you see instead?

Program launching and displaying some information instead I get the check fails.


What version of the product are you using? On what operating system?

/tmp/toto❯  uname -a
Linux host 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux
/tmp/toto❯  clangg --version
clang version 3.1 (trunk 148107)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Please provide any additional information below.

/tmp/toto❯ /projects/bin/tool
==30618== CHECK failed: (uintptr_t)&rl >= start && (uintptr_t)&rl < end at 
asan_linux.cc:248
    #0 0x84007b3 (tool+0x84007b3)
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class:



A simple test works :

/tmp/toto❯ clangg -g -c simple_main.c; clangg -g -o simple_main simple_main.o
clang: warning: argument unused during compilation: '-mllvm -asan-stack=1'
/tmp/toto❯ ./simple_main 
Do nothing except alloc & dealloc
Display test TEST
/tmp/toto❯ cat simple_main.c 
#include "stdio.h"
#include "stdlib.h"
#include "string.h"

int main(int argc, char const *argv[])
{
    printf("Do nothing except alloc & dealloc\n");
    char *test = calloc(30, sizeof (char));
    strncpy(test, "TEST", 30);
    printf("Display test %s\n", test);

    free(test);
    return 0;
}

As described in 
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Getting ,
I checked out the sources and they compile my simple helloworld-style app fine 
with -O1/-O2:

$ ~/asan/asan_clang_Linux/bin/clang -O2 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
$ ~/asan/asan_clang_Linux/bin/clang -O1 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
$ ~/asan/asan_clang_Linux/bin/clang -O0 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`Global::DescribeAddrIfMyRedZone(unsigned int)':
~/asan/asan_rtl.cc:305: undefined reference to `__asan_mapping_scale'
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`AddrIsInLowMem':
~/asan/asan_mapping.h:60: undefined reference to `__asan_mapping_offset'
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`AddrIsInHighMem':
~/asan/asan_mapping.h:68: undefined reference to `__asan_mapping_scale'
[many more...]
clang: error: linker command failed with exit code 1 (use -v to see invocation)

ASLR is bound to MH_PIE bit in the Mach-O header.
If a binary is built with --no_pie, ASLR is off and there's nothing to worry 
about.

For a program with MH_PIE bit set ASLR can be disabled at runtime:
 -- on Snow Leopard -- by setting DYLD_NO_PIE=1
 -- on Lion -- by passing the _POSIX_SPAWN_DISABLE_ASLR flag to posix_spawnattr_setflags (see http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/)

So there are several ways of dealing with ASLR:
 1. Always build with --no_pie if -faddress-sanitizer is on.
 2. At runtime check that the code segments do not interleave with the shadow and:
   2.1 Print an error message that tells to set DYLD_NO_PIE=1 on 10.6 or build with --no_pie on 10.7
   2.2 Do fork+exec to start a new process with ASLR disabled

Since the compiler option has been renamed to -faddress-sanitizer, the tool's 
connection to pheasants has become unclear.

1. application dlopens foo.so
2. asan registers all globals from foo.so
3. application closes foo.so
4. application mmaps some memory to the location where foo.so was before
5. application starts using this mmaped memory, but asan still thinks there are 
globals. 
6. BOOM

I'll create a unit test and then a fix. 

I have 64 bit RHEL 5.6, when i try to compile clang build failed. When I go to 
lib/Transforms/Instrumentation/ and run make, here is the output:
[root@nntcl28-2qcht clang_build_Linux]# cd lib/Transforms/Instrumentation/
[root@nntcl28-2qcht Instrumentation]# make
llvm[0]: Compiling AddressSanitizer.cpp for Release+Asserts build
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal: In static member function ‘static bool 
std::tr1::_Function_base::_Base_manager<_Functor>::_M_manager(std::tr1::_Any_dat
a&, const std::tr1::_Any_data&, std::tr1::_Manager_operation)’:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal:904: error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal: In static member function ‘static bool 
std::tr1::_Function_base::_Ref_manager<_Functor>::_M_manager(std::tr1::_Any_data
&, const std::tr1::_Any_data&, std::tr1::_Manager_operation)’:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal:982: error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal_iterate.h: In static member function ‘static bool 
std::tr1::_Function_handler<void ()(), _Member 
_Class::*>::_M_manager(std::tr1::_Any_data&, const std::tr1::_Any_data&, 
std::tr1::_Manager_operation)’:

tr1 headers can't be compiled without rtti but it seems option -fno-rtti 
presented in makefiles. I hope this is root case that my build failed.

There are two errors that are reported using Printf instead of Report, in 
asan_allocator.cc:

  691   AsanChunk *m = PtrToChunk((uintptr_t)ptr);
  692   if (m->chunk_state == CHUNK_QUARANTINE) {
  693     Printf("attempting double-free on %p:\n", ptr);
  694     stack->PrintStack();
  695     m->DescribeAddress((uintptr_t)ptr, 1);
  696     ShowStatsAndAbort();
  697   } else if (m->chunk_state != CHUNK_ALLOCATED) {
  698     Printf("attempting free on address which was not malloc()-ed: %p\n", ptr);
  699     stack->PrintStack();
  700     ShowStatsAndAbort();
  701   }


These two errors do not match the error reporting behavior of all other errors 
reported and are not easily recognizable by external tools. I suggest to use 
the attached patch which changes "Printf" to "Report" and adds "ERROR: 
AddressSanitizer" to the output as it is done for all other errors.


Using this small example for double-free (which is not in tests btw):

#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char));
  free(x);
  free(x);
  return 0;
}

I get the following error using the unpatched version:

attempting double-free on 0x7f784a9cb180:
    #0 0x7f784bb3d944 (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/bin_linux/libasan64.so+0x7944)
    #1 0x4008ae (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/tests/double-free+0x4008ae)
    #2 0x7f784b2a3c9d (/lib64/libc-2.12.so+0x1ec9d)

and with the patch:

==32367== ERROR: AddressSanitizer - attempting double-free on 0x7f784a9cb180:
    #0 0x7f784bb3d944 (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/bin_linux/libasan64.so+0x7944)
    #1 0x4008ae (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/tests/double-free+0x4008ae)
    #2 0x7f784b2a3c9d (/lib64/libc-2.12.so+0x1ec9d)


The other branch could be tested using this small program (called it wild-free):

#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char));
  x += 10;
  free(x);
  return 0;
}

On Mac 64-bit asan start-up is insanely slow. 
I suspect this is caused by mach_override, please investigate.

The blacklist in the AddressSanitizer pass constructs one big regular 
expression from the blacklist entries. If one of these list entries contains 
something illegal, then the whole regex silently fails and nothing is 
blacklisted. Also no error is emitted for this.

To test this, create a blacklist using:

fun:main
fun:foo??bar
fun:bar

The second line here is invalid (at least it seems to be in the C++ regular 
expression library that is used, as it stopped my blacklist from working. Using 
this blacklist won't have any effect, e.g. main will be instrumented.

Tested using LLVM/Clang/ASan SVN trunk revision 146212 on Linux.

When instrumenting global arrays, we add fixed-size redzones (32 bytes) to them.
If the array has two or more dimensions, we're likely to miss the redzone even 
if the array index is off by one:

char arr[40][40];
char arr2[40];

arr[40][0] = 'a';  // this will hit arr2


We may want to vary the size for two-dimensional arrays depending on their 
sizes.

This LLVM revision 
<http://llvm.org/viewvc/llvm-project?view=rev&revision=131330> has a bug fix 
for LLVM generating invalid AVX instructions.

When I was trying to use AddressSanitizer on Firefox, I was bitten by this bug. 
 The fix is simple, we should just upgrade the LLVM used by AddressSanitizer to 
r131330.

The attached patch does that.

We basically need to implement AsanProcMaps::GetObjectNameAndOffset on Mac and 
then get rid of the sysinfo.cc completely. 

What steps will reproduce the problem?

$ cat try.c
#include <stdio.h>
int main() { printf("Ok\n"); return(0); }

$ clang -o try -g3 -D__APPLE__ -faddress-sanitizer try.c
$ ./try
Ok==33560== 
CHECK failed: summary at asan_thread_registry.cc:99, pthread_self=0x7fff70989cc0
Segmentation fault

$ gdb ./try
(gdb) r
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000010000b3af in __asan::AsanThread::ClearShadowForThreadStack 
(this=0x10242a9a0) at asan_thread.cc:51
#2  0x000000010000b6b1 in __asan::AsanThread::~AsanThread (this=0x10242a9a0) at 
asan_thread.cc:45
#3  0x000000010000c3d0 in __asan::AsanThreadRegistry::~AsanThreadRegistry 
(this=0x10042a9a0) at asan_thread_registry.h:29
#4  0x000000010000fe15 in __tcf_0 () at asan_thread_registry.cc:24
#5  0x00007fff8640a374 in __cxa_finalize ()
#6  0x00007fff8640a28c in exit ()
#7  0x0000000100000f53 in start () at asan_thread_registry.h:28

(gdb) up
(gdb) p *this
$1 = {
  static kInvalidTid = -1, 
  summary_ = 0x0, 
  start_routine_ = 0, 
  arg_ = 0x0, 
  stack_top_ = 0, 
  stack_bottom_ = 0, 
  fake_stack_ = {
    static kMinStackFrameSizeLog = 9, 
    static kMaxStackFrameSizeLog = 16, 
    static kMaxStackMallocSize = 65536, 
    static kNumberOfSizeClasses = 8, 
    stack_size_ = 0, 
    alive_ = false, 
    allocated_size_classes_ = {0, 0, 0, 0, 0, 0, 0, 0}, 
...

$ clang --version
clang version 3.1 (trunk 144800)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

The attached patch fixed it for me

We need to symbolize error messages in process. 
Looks like we can share some code with lldb. 
See http://comments.gmane.org/gmane.comp.debugging.lldb.devel/650

Such code will be useful for other dynamic tools as well. 

Hello,

I realize that it's only been tested on Ubuntu, but I was trying to run it on 
centos (5.6 x86_64).

I assume Ubuntu comes with a newer version of libc, since it's failing to link.

Is there a way to build clang on Centos?

Mike



[root@prague mike]# ./asan/asan_clang_Linux/bin/clang

./asan/asan_clang_Linux/bin/clang: /lib64/libc.so.6: version `GLIBC_2.11'
not found (required by ./asan/asan_clang_Linux/bin/clang)

./asan/asan_clang_Linux/bin/clang: /usr/lib64/libstdc++.so.6: version 
`GLIBCXX_3.4.9' not found (required by ./asan/asan_clang_Linux/bin/clang)

[root@prague mike]# ls -la /lib64/libc.so.6
lrwxrwxrwx 1 root root 11 Apr 14 19:58 /lib64/libc.so.6 -> libc-2.5.so

[root@prague mike]# ls -la /usr/lib64/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Apr 14 19:59 /usr/lib64/libstdc++.so.6 ->
libstdc++.so.6.0.8

[root@prague mike]# more /etc/redhat-release 
CentOS release 5.6 (Final)

What steps will reproduce the problem?
1. link the main program against libgflags.so
2. the program runs normally.
3. link the main program against libgflags.a
4. the program crashes and cores dump before main.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
latest llvm 3.1

Please provide any additional information below.
Is there any trick in gflags that makes it incompatible to asan when static 
linked?

ASan does not catch global buffer overflow in the following example:

#include <stdio.h>

__attribute__((weak)) char zz[10] = "012345678";

int main(void) {
        for (int i = 0; i < 11; ++i) {
                zz[i] = '5';
        }
        printf("%s\n", zz);
        return 0;
}

[deleted issue]

Chrome uses mach_override framework, and its version differs slightly from that 
we are using. At the moment linking ASan with Chrome tests causes them to fail, 
because we're trying to call instrumented versions of mach_override_ptr(), 
allocateBranchIsland() etc. from the ASan runtime. Even if we don't instrument 
those functions, we still get the wrong implementation of mach_override_ptr, 
which may not cope with some of the functions we need to override.

mach_override is written in C, thus we can't use namespaces.

What steps will reproduce the problem?
1. rm -rf third_party/googletest
2. svn co http://googletest.googlecode.com/svn/trunk -r608 
third_party/googletest
3. <rebuild ASan>
4. make -f Makefile.old t32

What is the expected output? What do you see instead?
Linker produces error:
/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/lib/asan/../../.
./../build/Release+Asserts/bin/clang++  -faddress-sanitizer 
-DADDRESS_SANITIZER=1 -mllvm 
-asan-blacklist=/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/
lib/asan/tests/asan_test.ignore -mllvm -asan-stack=1 -mllvm -asan-globals=1 
-mllvm -asan-use-call=1 -mllvm -asan-mapping-scale=0   -mllvm 
-asan-mapping-offset-log=-1   -mllvm -asan-use-after-return=0 -DASAN_UAR=0 
-DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DASAN_HAS_BLACKLIST=1 -I../include 
-Wall -fvisibility=hidden -m32 -g -w -lpthread sample1.o sample1_unittest.o 
gtest_main.a -o sample1_unittest

<some clang warnings>

/usr/bin/ld: gtest_main.a(gtest-all.o)(.text+0x7cb7c): unresolvable R_386_PC32 
relocation against symbol `sigaction@@GLIBC_2.0'
/usr/bin/ld: final link failed: Nonrepresentable section on output

I recently tried a Firefox+ASan build with optimization turned on. During 
startup I saw an ASan abort due to a stack buffer overflow in libpng code 
(which only happens in the optimized version). I inspected the code and it's 
impossible that an overflow is happening at the given location.

However, I managed to extract a testcase and minimized it by automatic means 
with respect to code and involved compiler flags. It turned out that the 
combination of -faddress-sanitizer and -Os is the problem, -O2 produces the 
same. Using -O1 or -O0 though works. The test is attached: To reproduce, unpack 
the archive, run "make" and then execute ./main.

Tested this on 64 bit with LLVM/Clang/compiler-rt revision 146212.


Main output is:

==25258== ERROR: AddressSanitizer stack-buffer-overflow on address 
0x7fff94e82cb0 at pc 0x4019ff bp 0x7fff94e82c50 sp 0x7fff94e82c48
READ of size 8 at 0x7fff94e82cb0 thread T0
    #0 0x4019ff (testAsanOptimizeSize/main+0x4019ff)
    #1 0x401929 (testAsanOptimizeSize/main+0x401929)
    #2 0x7f76bd049eff (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeff)
Address 0x7fff94e82cb0 is located at offset 48 in frame <test> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'


The function init just initializes the buffer while finish just prints the 
values. I moved these to a separate compilation unit so the access isn't 
entirely optimized away.

This is best reproducible with pdfsqueeze from the Chromium tree (see 
http://dev.chromium.org/developers/testing/addresssanitizer for the build 
instructions; the target name is pdfsqueeze)

# input.pdf must be a valid pdf, probably one of those in the Chromium tree.
$ out/Release/pdfsqueeze input.pdf output.pdf
terminate called after throwing an instance of 'CMMException'
Abort trap

$ gdb out/Release/pdfsqueeze
...
(gdb) break wrap___cxa_throw 
Breakpoint 1 at 0xcb9d
(gdb) r input.pdf output.pdf

Breakpoint 1, 0x0000cb9d in wrap___cxa_throw ()
(gdb) bt
#0  0x0000cb9d in wrap___cxa_throw ()
#1  0x90d0d292 in CMMThrowExceptionOnError ()
#2  0x90d131b7 in CMMCurveTag::CMMCurveTag ()
#3  0x90d15651 in CMMParaCurveTag::CMMParaCurveTag ()
#4  0x90d259f8 in CMMProfile::MakeTag ()
#5  0x90d25dbd in CMMProfile::GetTag ()
#6  0x90d28049 in CMMProfile::GetCurveTag ()
#7  0x90d2808e in CMMProfile::InnerGetMatrixTags ()
#8  0x90d28170 in CMMMatrixDisplayProfile::GetMatrixTags ()
#9  0x90d2d4a7 in ConversionManager::MakeConversionSequence ()
#10 0x90d2eecb in DoInitializeTransform ()
#11 0x90d2f5ec in AppleCMMInitializeTransform ()
#12 0x90d5ec24 in ColorSyncCMMInitializeTransform ()
#13 0x90cffec6 in ColorSyncTransformCreate ()
#14 0x94a5795b in create ()
#15 0x94a51019 in aquireColorWorldByAttributes ()
#16 0x94a50e46 in acquireColorWorld ()
#17 0x94a50d05 in CMSTransformConvertComponents ()
#18 0x99637c9d in CGCMSInterfaceTransformConvertColorComponents ()
#19 0x99636e31 in CGColorTransformConvertColorFloatComponents ()
#20 0x99636cde in CGColorTransformConvertColorComponents ()
#21 0x01728e5a in FilterGStateColor ()
#22 0x01729211 in FilterGState ()
#23 0x0172a155 in ctxftr_DrawPath ()
#24 0x996cd68f in CGContextDrawPath ()
#25 0x996e5c9b in CGPDFDrawingContextDrawPath ()
#26 0x996e7b47 in op_f ()
#27 0x996e4dcc in pdf_scanner_handle_xname ()
#28 0x996e3ed4 in CGPDFScannerScan ()
#29 0x996e1ff0 in CGPDFDrawingContextDrawPage ()
#30 0x996e1c8a in CGContextDrawPDFPageWithProgressCallback ()
#31 0x996e1c24 in CGContextDrawPDFPage ()
#32 0x94c25bf9 in -[PDFPage(PDFPagePrivate) drawWithBox:inContext:] ()
#33 0x94c1e82b in -[PDFPage drawWithBox:] ()
#34 0x94c1c931 in -[PDFDocument(PDFDocumentInternal) 
writeToConsumer:withOptions:] ()
#35 0x94c1be42 in -[PDFDocument writeToURL:withOptions:] ()
#36 0x0000a060 in main (argc=3, argv=<value temporarily unavailable, due to 
optimizations>) at third_party/pdfsqueeze/pdfsqueeze.m:64


(gdb) disas
Dump of assembler code for function wrap___cxa_throw:
0x0000cb90 <wrap___cxa_throw+0>:    push   %ebp
0x0000cb91 <wrap___cxa_throw+1>:    push   %ebx
0x0000cb92 <wrap___cxa_throw+2>:    push   %edi
0x0000cb93 <wrap___cxa_throw+3>:    push   %esi
0x0000cb94 <wrap___cxa_throw+4>:    sub    $0x1c,%esp
0x0000cb97 <wrap___cxa_throw+7>:    call   0xcb9c <wrap___cxa_throw+12>
0x0000cb9c <wrap___cxa_throw+12>:   pop    %esi
0x0000cb9d <wrap___cxa_throw+13>:   call   0x8ae0 
<_ZN6__asan18asanThreadRegistryEv>
0x0000cba2 <wrap___cxa_throw+18>:   mov    %eax,(%esp)
0x0000cba5 <wrap___cxa_throw+21>:   call   0x8c70 
<_ZN6__asan18AsanThreadRegistry10GetCurrentEv>
0x0000cbaa <wrap___cxa_throw+26>:   test   %eax,%eax
0x0000cbac <wrap___cxa_throw+28>:   je     0xcbf9 <wrap___cxa_throw+105>
0x0000cbae <wrap___cxa_throw+30>:   mov    0x38(%esp),%edi
0x0000cbb2 <wrap___cxa_throw+34>:   mov    0x34(%esp),%ebx
0x0000cbb6 <wrap___cxa_throw+38>:   mov    0x30(%esp),%ebp
0x0000cbba <wrap___cxa_throw+42>:   lea    -0xfe8(%esp),%ecx
0x0000cbc1 <wrap___cxa_throw+49>:   and    $0xfffff000,%ecx
0x0000cbc7 <wrap___cxa_throw+55>:   mov    0xc(%eax),%eax
0x0000cbca <wrap___cxa_throw+58>:   sub    %ecx,%eax
0x0000cbcc <wrap___cxa_throw+60>:   mov    %eax,0x4(%esp)
0x0000cbd0 <wrap___cxa_throw+64>:   mov    %ecx,(%esp)
0x0000cbd3 <wrap___cxa_throw+67>:   movl   $0x0,0x8(%esp)
0x0000cbdb <wrap___cxa_throw+75>:   call   0x54f0 <_ZN6__asan12PoisonShadowEmmh>
0x0000cbe0 <wrap___cxa_throw+80>:   mov    %edi,0x8(%esp)
0x0000cbe4 <wrap___cxa_throw+84>:   mov    %ebx,0x4(%esp)
0x0000cbe8 <wrap___cxa_throw+88>:   mov    %ebp,(%esp)
0x0000cbeb <wrap___cxa_throw+91>:   call   *0x64e8(%esi)
0x0000cbf1 <wrap___cxa_throw+97>:   add    $0x1c,%esp
0x0000cbf4 <wrap___cxa_throw+100>:  pop    %esi
0x0000cbf5 <wrap___cxa_throw+101>:  pop    %edi
0x0000cbf6 <wrap___cxa_throw+102>:  pop    %ebx
0x0000cbf7 <wrap___cxa_throw+103>:  pop    %ebp
0x0000cbf8 <wrap___cxa_throw+104>:  ret    
0x0000cbf9 <wrap___cxa_throw+105>:  lea    0x2340(%esi),%eax
0x0000cbff <wrap___cxa_throw+111>:  mov    %eax,0x4(%esp)
0x0000cc03 <wrap___cxa_throw+115>:  lea    0x32d3(%esi),%eax
0x0000cc09 <wrap___cxa_throw+121>:  mov    %eax,(%esp)
0x0000cc0c <wrap___cxa_throw+124>:  movl   $0x1e6,0x8(%esp)
0x0000cc14 <wrap___cxa_throw+132>:  call   0x5f00 
<_ZN6__asan11CheckFailedEPKcS1_i>
0x0000cc19 <wrap___cxa_throw+137>:  nopl   0x0(%eax)
End of assembler dump.

Let's stop before real___cxa_throw:
0x0000cbeb <wrap___cxa_throw+91>:   call   *0x64e8(%esi)

(gdb) break *0x0000cbeb
Breakpoint 4 at 0xcbeb
(gdb) c

(gdb) bt
#0  0x0000cbeb in wrap___cxa_throw ()
#1  0x90d0d292 in CMMThrowExceptionOnError ()
#2  0x90d131b7 in CMMCurveTag::CMMCurveTag ()
#3  0x90d15651 in CMMParaCurveTag::CMMParaCurveTag ()
#4  0x90d259f8 in CMMProfile::MakeTag ()
#5  0x90d25dbd in CMMProfile::GetTag ()
#6  0x90d28049 in CMMProfile::GetCurveTag ()
#7  0x90d2808e in CMMProfile::InnerGetMatrixTags ()
#8  0x90d28170 in CMMMatrixDisplayProfile::GetMatrixTags ()
#9  0x90d2d4a7 in ConversionManager::MakeConversionSequence ()
#10 0x90d2eecb in DoInitializeTransform ()
#11 0x90d2f5ec in AppleCMMInitializeTransform ()
#12 0x90d5ec24 in ColorSyncCMMInitializeTransform ()
#13 0x90cffec6 in ColorSyncTransformCreate ()
#14 0x94a5795b in create ()
#15 0x94a51019 in aquireColorWorldByAttributes ()
#16 0x94a50e46 in acquireColorWorld ()
#17 0x94a50d05 in CMSTransformConvertComponents ()
#18 0x99637c9d in CGCMSInterfaceTransformConvertColorComponents ()
#19 0x99636e31 in CGColorTransformConvertColorFloatComponents ()
#20 0x99636cde in CGColorTransformConvertColorComponents ()
#21 0x01728e5a in FilterGStateColor ()
#22 0x01729211 in FilterGState ()
#23 0x0172a155 in ctxftr_DrawPath ()
#24 0x996cd68f in CGContextDrawPath ()
#25 0x996e5c9b in CGPDFDrawingContextDrawPath ()
#26 0x996e7b47 in op_f ()
#27 0x996e4dcc in pdf_scanner_handle_xname ()
#28 0x996e3ed4 in CGPDFScannerScan ()
#29 0x996e1ff0 in CGPDFDrawingContextDrawPage ()
#30 0x996e1c8a in CGContextDrawPDFPageWithProgressCallback ()
#31 0x996e1c24 in CGContextDrawPDFPage ()
#32 0x94c25bf9 in -[PDFPage(PDFPagePrivate) drawWithBox:inContext:] ()
#33 0x94c1e82b in -[PDFPage drawWithBox:] ()
#34 0x94c1c931 in -[PDFDocument(PDFDocumentInternal) 
writeToConsumer:withOptions:] ()
#35 0x94c1be42 in -[PDFDocument writeToURL:withOptions:] ()
#36 0x0000a060 in main (argc=3, argv=<value temporarily unavailable, due to 
optimizations>) at third_party/pdfsqueeze/pdfsqueeze.m:64

(gdb) stepi
0xffc23000 in ?? ()
(gdb) bt
#0  0xffc23000 in ?? ()
#1  0x0000cbf1 in wrap___cxa_throw ()

Note we already can't unwind at the first instruction of the branch island 
allocated by mach_override_ptr.

(gdb) disas 0xffc23000 0xffc23020
Dump of assembler code from 0xffc23000 to 0xffc23020:
0xffc23000: push   %ebp
0xffc23001: mov    %esp,%ebp
0xffc23003: push   %esi
0xffc23004: push   %ebx
0xffc23005: nop    
0xffc23006: nop    
0xffc23007: nop    
0xffc23008: nop    
0xffc23009: nop    
0xffc2300a: nop    
0xffc2300b: nop    
0xffc2300c: nop    
0xffc2300d: nop    
0xffc2300e: nop    
0xffc2300f: nop    
0xffc23010: jmp    0x91448250 <__cxa_throw+5>
0xffc23015: add    %al,(%eax)
0xffc23017: add    %al,(%ecx)
0xffc23019: add    %al,(%eax)
0xffc2301b: add    %al,(%eax)
0xffc2301d: add    %al,(%eax)
0xffc2301f: add    %al,(%eax)

(gdb) c
Continuing.
terminate called after throwing an instance of 'CMMException'

Program received signal SIGABRT, Aborted.
0x94abac5a in __kill ()

(gdb) bt
#0  0x94abac5a in __kill ()
#1  0x94abac4c in kill$UNIX2003 ()
#2  0x94b4d5a5 in raise ()
#3  0x94b636e4 in abort ()
#4  0x91449fda in __gnu_cxx::__verbose_terminate_handler ()
#5  0x9144817a in __cxxabiv1::__terminate ()
#6  0x914481ba in std::terminate ()
#7  0x914482b8 in __cxa_throw ()
#8  0x0000cbf1 in wrap___cxa_throw ()


I believe the problem with stack unwinding leads to incorrect exception 
handling. If so, other wrapped functions that may throw exceptions (fortunately 
we don't have any yet) may be affected.
If we don't wrap __cxa_throw(), the problem goes away.

$ cat t.c
int volatile a[5];
int main() {
  a[5] = 1;
  return 0;
}

$ ../../../../build/Release+Asserts/bin/clang -faddress-sanitizer t.c -o t && 
./t
<nothing here>

$ ../../../../build/Release+Asserts/bin/clang++ -faddress-sanitizer t.c -o t pp 
&& ./tpp

=================================================================
==44106== ERROR: AddressSanitizer global-buffer-overflow on address 
0x000100015834 at pc 0x100007230 bp 0x7fff5fbff990 sp 0x7fff5fbff988
WRITE of size 4 at 0x000100015834 thread T0
    #0 0x100007230 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x7230)
    #1 0x100007084 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x7084)
    #2 0x1 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x1)
0x000100015834 is located 0 bytes to the right of global variable 'a (t.c)' 
(0x100015820) of size 20
  'a (t.c)' is ascii string ''
==44106== ABORTING
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 0 small slow: 0
Shadow byte and word:
  0x100020002b06: 4
  0x100020002b00: 00 00 00 00 00 00 04 f9
More shadow bytes:
  0x100020002ae0: 00 00 00 00 00 00 00 00
  0x100020002ae8: 00 00 00 00 00 00 00 00
  0x100020002af0: 00 00 00 00 00 00 00 00
  0x100020002af8: 00 00 00 00 00 00 00 00
=>0x100020002b00: 00 00 00 00 00 00 04 f9
  0x100020002b08: f9 f9 f9 f9 00 00 00 00
  0x100020002b10: 00 00 00 00 00 00 00 00
  0x100020002b18: 00 00 00 00 00 00 00 00
  0x100020002b20: 00 00 00 00 00 00 00 00

clang -mllvm -asan-blacklist=asan_blacklist.ignore
currently fails on a missing asan_blacklist.ignore file.

I improved the error message.

And I prefer a warning over the fatal exit as I have multiple blacklist 
files in relative paths, but only for certain subprojects.
Missing a blacklist file should just produce a warning IMHO.

patch attached.

=====================================================================
#import <Foundation/Foundation.h>
#import <WebKit/WebKit.h>

@interface WebKitDelegate : NSObject
@end

@implementation WebKitDelegate

- (void)webView:(WebView *)sender didFinishLoadForFrame:(WebFrame *)frame
{
    NSLog(@"didFinishLoadForFrame");
    [sender displayIfNeeded];
    if (frame == [sender mainFrame])
        exit(0);
}

- (NSURLRequest *)webView:(WebView *)sender resource:(id)identifier 
willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse 
*)redirectResponse fromDataSource:(WebDataSource *)dataSource;
{
    NSLog(@"Will send request %@ (redirect %@)",request,redirectResponse);
    return request;
}

- (void)webView:(WebView *)sender resource:(id)identifier 
didReceiveResponse:(NSURLResponse *)response fromDataSource:(WebDataSource 
*)dataSource
{
    NSLog(@"Got response %@",response);
}
@end

int main(int argc, char * const argv[])
{
    //// CFAllocatorSetDefault(kCFAllocatorMallocZone);
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    WebView *webView = [[WebView alloc] initWithFrame:NSMakeRect(0, 0, 800, 600) frameName:nil groupName:@"org.webkit.parseWebKit"];
    WebKitDelegate* delegate = [[WebKitDelegate alloc] init];
    [webView setFrameLoadDelegate:delegate];
    [webView setResourceLoadDelegate:delegate];
    [[webView mainFrame] loadHTMLString:@"<html><body>test</body></html>" baseURL:nil];
    [[NSRunLoop currentRunLoop] run];
    [pool drain];
    return 0;
}
=====================================================================

The program above hangs under ASan. If the "CFAllocatorSetDefault" line is 
uncommented, the program hangs without ASan.