search

gopalshankar / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
0 stars 0 forks source link

asan should check malloc/delete or new/free mismatch #131

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
subj

Original issue reported on code.google.com by konstant...@gmail.com on 3 Dec 2012 at 12:06

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

Original comment by konstant...@gmail.com on 21 Dec 2012 at 8:55

GoogleCodeExporter commented 9 years ago 
FTR, I'll also need to add OS X interceptors in order for this to work.

Original comment by ramosian.glider@gmail.com on 21 Dec 2012 at 9:41

GoogleCodeExporter commented 9 years ago 
This feature is now enabled by default on Linux, but not on Mac.

Original comment by konstant...@gmail.com on 14 Jan 2013 at 2:05

GoogleCodeExporter commented 9 years ago 
I've temporarily disabled the new/delete implementations on OSX

Original comment by ramosian.glider@gmail.com on 22 Jan 2013 at 11:39

GoogleCodeExporter commented 9 years ago

Original comment by gli...@chromium.org on 28 Jan 2013 at 3:19

GoogleCodeExporter commented 9 years ago 
Fixed as of r174628.

Original comment by ramosian.glider@gmail.com on 7 Feb 2013 at 4:03

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ramosian.glider@gmail.com on 23 Apr 2013 at 12:16

GoogleCodeExporter commented 9 years ago 
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.

Original comment by euge...@chromium.org on 23 Apr 2013 at 12:28

GoogleCodeExporter commented 9 years ago 
Forget it, won't work.

Original comment by euge...@google.com on 23 Apr 2013 at 12:47