ASan: suppress new-delete-type-mismatch via ASAN_OPTIONS suppressions?

I need to suppress a new-delete-type-mismatch reported in an external library. ASan suggests a global ASAN_OPTIONS=new_delete_type_mismatch=0, but I noticed that there's an ASAN_OPTIONS=suppressions=... feature now, so I thought I might be able to make the suppression more targeted.

However, interceptor_via_fun/lib appears to only be targeting the various interceptors in lib/asan/asan_interceptors.cc, not ReportNewDeleteSizeMismatch called from lib/asan/asan_allocator.cc. But a simple hack

diff --git a/lib/asan/asan_allocator.cc b/lib/asan/asan_allocator.cc
index fb433bb..393f80a 100644
--- a/lib/asan/asan_allocator.cc
+++ b/lib/asan/asan_allocator.cc
@@ -20,6 +20,7 @@
#include "asan_poisoning.h"
#include "asan_report.h"
#include "asan_stack.h"
+#include "asan_suppressions.h"
#include "asan_thread.h"
#include "sanitizer_common/sanitizer_allocator_interface.h"
#include "sanitizer_common/sanitizer_flags.h"
@@ -530,6 +531,7 @@ struct Allocator {

     if (delete_size && flags()->new_delete_type_mismatch &&
         delete_size != m->UsedSize()) {
+if (!IsStackTraceSuppressed(stack))
       ReportNewDeleteSizeMismatch(p, m->UsedSize(), delete_size, stack);
     }

showed that it would work to (mis-/re-?)use the suppression file's interceptor_via_fun/lib also for reports from ASan's allocation "interceptor".

Would that be something that is fine as-is (extending it to also cover other Reports from the allocator, like ReportAllocTypeMismatch called a few lines above in Allocator::Deallocate), or what do people think?

Sorry for delay. (cfe-dev is not the list I usually monitor for asan problems).

Suppressing new-delete mismatches might be useful in some rare cases
(and maybe yours is like this: buggy third party code that you don’t control).
But I am reluctant to add more suppression mechanisms unless many people ask for it (extra complexity is justified only if there are enough users who need it; you are the first, AFAICT. I am especially careful with suppressions as I’ve seen them hurt the testing process many times).

If you feel strong, please send a patch with a test and doc update to llvm-commits
using phabricator. (CC me and eugenis@google.com).

–kcc

Sorry for delay. (cfe-dev is not the list I usually monitor for asan
problems).

Ah, yeah, wasn't sure which list is best to discuss sanitizer issues.

Suppressing new-delete mismatches might be useful in some rare cases
(and maybe yours is like this: buggy third party code that you don't
control).
But I am reluctant to add more suppression mechanisms unless many people
ask for it (extra complexity is justified only if there are enough users
who need it; you are the first, AFAICT. I am especially careful with
suppressions as I've seen them hurt the testing process many times).

If you feel strong, please send a patch with a test and doc update to
llvm-commits
using phabricator. (CC me and eugenis@google.com
<mailto:eugenis@google.com>).

Had already filed <http://reviews.llvm.org/D21378&gt; meanwhile. Will add a doc update to it in any case. Anyway, if you don't want suppression support to go in that direction, we can also drop it.

So I had another look now, trying to add the requested doc update. However, I have no idea what I'm supposed to add where: docs/AddressSanitizer.rst in the clang repo is the only place I found discussing the ASan suppression mechanism. But it doesn't explain what error reports exactly can be suppressed with that mechanism. It starts of with a vague "Runtime interposition allows AddressSanitizer to find bugs in code that is not being recompiled." Which IMO already covers this new-delete-type-mismatch report (via interposition of C++ new/delete handling) just as well as it covers whatever other interposition.