LLVM r170869:
[asan] add a flag alloc_dealloc_mismatch (off by default for now) which finds malloc/delete,
new/free, new/delete[], etc mismatches

FTR, I'll also need to add OS X interceptors in order for this to work.

This feature is now enabled by default on Linux, but not on Mac. 

I've temporarily disabled the new/delete implementations on OSX

Fixed as of r174628.

This is still broken. Citing myself from http://llvm.org/bugs/show_bug.cgi?id=15544:

"""
The current ASan implementation of custom new()/delete() does not work reliably
on Mac (it may occasionally, but that's fake safety). Because the ASan runtime
library is a DSO, we end up having the main executable depend on two DSOs
(libstdc++ and libclang_rt.asan_osx_dynamic) each having their own new/delete
implementation. It's not determined which of them is picked at startup (I saw
both versions already).
Until we decide how to make ASan reliably intercept new/delete on OS X we just
need to disable our custom interceptors - that should fix the new_handler
issue.
"""

I've disabled alloc_dealloc_mismatch and the corresponding tests on OS X for now.

A crazy idea follows.
What if we add a weak undefined symbol to asan runtime that can be resolved by libstdc++?
This way asan runtime will depend on libstdc++ (if it is linked to the executable at
all). This will force the lookup order.

Forget it, won't work.

Adding Project:AddressSanitizer as part of GitHub migration.