By removing new/delete interceptors we also lose allocation stacks on ARM, because standard
C++ libraries are often built without frame pointers, or with incompatible frame pointers
(ARM has no standard FP location in the stack frame).

Reported by eugenis@google.com on 2014-04-15 12:11:10

I agree with Evgeniy - dropping new/delete replacements is a bad idea - we will almost
certainly have worse stack traces even on Linux. Splitting ASan runtime in two parts
(i.e. moving C++-specific bits into a separate library and link it if necessary) is
quite possible - we do it in UBSan already (there are clang_rt.ubsan.a and clang_rt.ubsan_cxx.a),
and have the required logic in driver.

Reported by samsonov@google.com on 2014-04-15 21:26:12

let us split the run-time first. 

Reported by konstantin.s.serebryany on 2014-04-16 07:20:38

Oh, good.
Having an example to work from will make it much easier, I suspect.

� Marshall

Reported by mclow.lists on 2014-04-16 13:41:30

http://llvm.org/bugs/show_bug.cgi?id=19660 is asking to support 
custom operator new()

Reported by konstantin.s.serebryany on 2014-05-06 11:42:19

http://llvm.org/viewvc/llvm-project?view=revision&revision=208609 splits ASan runtime
in two parts. Now it should be possible to add better support for bad_alloc, and compile
asan_cxx part with exceptions.

Reported by samsonov@google.com on 2014-05-12 18:48:53

I've just spent many many hours ensuring the libstdc++ testsuite can run with sanitizers, and all our code for handling allocation failure is untestable due to this issue. Every test that tries to handle std::bad_alloc either crashes when ASan fails to allocate, or crashes when it returns null and we dereference it.

This makes ASan unusable for testing large pieces of the C++ standard library.

And to be clear,

operator new is not fully standard-compliant

is inaccurate, it directly violates an absolute requirement of the standard.

That's not just a case of being "not fully standard-compliant".

We would be happy to accept small incremental patches fixing the problem piece-by-piece,
but at the moment we don't have enough hands to fix it ourselves.
While I totally agree that the current behavior is not standard compliant,
the only ones to complain are the libc++ developers.

I tried to make a patch to compiler-rt to fix this, but ran into the fact that you build w/exceptions disabled.

the only ones to complain are the libc++ developers.

And the libstdc++ maintainer.

mclow@, yes, we will need to change the build rules to build a small part of run-time w/ exceptions.

Do we really need to enable exceptions? Can't we just call __cxa_throw from __asan_new?

And __cxa_allocate and construct a bad_alloc object.

For libstdc++ you can call std::__throw_bad_alloc() but that doesn't help for libc++ or anything that isn't linked to libstdc++.so (including GCC-compiled code only linked to libsupc++.so)

I'd be happy to make libc++ provide a __throw_bad_alloc() call.

A solution that will not require us to change the build flags is more welcome of course.
But it will need to work with all flavors of the C++ std lib (libc++ and libstdc++, old and new) w/o recompilation of asan run-time.

Actually, libc++ already has a std:: __throw_bad_alloc (and it is in std, not std:__1

It'd be cool if there was a way to set allocator_may_return_null=1 only for new (std::nothrow). In Chromium, we like regular operator new to crash, but we'd like nothrow new to return 0. We currently disable at least one test in asan mode because it catches nothrow new that would return 0.

(sorry for delay... yes, I afraid we need to do that)

Awfully belated update, everything requested (except throwing std::bad_alloc) is implemented as of July 2017.

everything requested (except throwing std::bad_alloc) is implemented as of July 2017.

That's encouraging.
Just to avoid confusion, I read this as, under ASAN:

• operator new (nothrow) returns null on allocation failure.
• All flavors of operator new (and boy, there are a lot of them!) call the new_handler and retry the allocation when it fails.
  But
• operator new still does not throw bad_alloc upon allocation failure.

Is that correct?

(and thanks for the update!)

Ah, the new_handler, indeed...

So, to recap. With allocator_may_return_null=0, allocator always crashes on failure, the rest assumes allocator_may_return_null=1

• operator new always crashes on failure
• operator new (nothrow) returns null
• all malloc/calloc/etc implementations follow their specifications, including setting errno (except dynamic runtime on Windows case)

TODO:

• make operator new to throw std::bad_alloc upon allocation failure
• call new_handler from operator new and retry the allocation

the only ones to complain are the libc++ developers.

And the libstdc++ maintainer.

And an MSVC STL maintainer.

Nice to see MSVC joining the party. :-)

FWIW, not just C++ STL developers. This effectively makes [oss-]fuzzing code
that may legitimately allocate large memory amounts generally impossible.
(Can sanitizer be queried if it can allocate N more bytes? I don't think so?)