This is an archive of the discontinued LLVM Phabricator instance.

[asan] Reports suppressions for ASan recovery mode (LLVM core part).
AbandonedPublic

Authored by m.ostapenko on Nov 30 2015, 7:50 AM.

Details

Summary

Hi!

When we run sanitized application in ASan recovery mode, sometimes we have lots of identical reports for the same error (e.g. error in hot loop). It would be nice to filter out such reports.
We can use the same approach as for UBSan with disabling source locations to achieve this goal.

This is the LLVM part of suppression functionality. Here, we just create SourceLocation descriptor for each memory access and provide a pointer to it for asan_report*_noabort functions.
There aren't any changes in default halt_on_error mode.

Diff Detail

Event Timeline

m.ostapenko retitled this revision from to [asan] Reports suppressions for ASan recovery mode (LLVM core part)..
m.ostapenko updated this object.
m.ostapenko added reviewers: kcc, eugenis, samsonov.
m.ostapenko set the repository for this revision to rL LLVM.
m.ostapenko added subscribers: ygribov, llvm-commits.
ygribov added inline comments.Nov 30 2015, 9:03 AM
lib/Transforms/Instrumentation/AddressSanitizer.cpp
1017

Is it possible move call out of if-else and set argument ArrayRefs there instead? Same for other places below.

1469

Perhaps used nested conditional operator?

kcc edited edge metadata.Nov 30 2015, 11:08 AM

Can't we just rely on __builtin_return_address to deduplicate reports?

The was this is done in ubsan is not necassary the best way for asan.
ubsan was initially designed to work with no or very lightweight run-time.

Can't we just rely on __builtin_return_address to deduplicate reports?

You mean poison shadow of return address with some meaningful value? This would work although I'm scared of shared libraries (e.g. if they are unmapped, etc.).

kcc added a comment.Nov 30 2015, 12:57 PM

You mean poison shadow of return address with some meaningful value? This would work although I'm scared of shared libraries (e.g. if they are unmapped, etc.).

No. You can just remember the return address in an array, and when reporting another bug consult that array.

In D15079#298845, @kcc wrote:

You mean poison shadow of return address with some meaningful value? This would work although I'm scared of shared libraries (e.g. if they are unmapped, etc.).

No. You can just remember the return address in an array, and when reporting another bug consult that array.

E.g. remember, say, last ten return addresses into array and just lookup there for given caller PC? This sounds reasonable for me.

kcc added a comment.Nov 30 2015, 6:24 PM
In D15079#298852, @m.ostepenko wrote:
In D15079#298845, @kcc wrote:

You mean poison shadow of return address with some meaningful value? This would work although I'm scared of shared libraries (e.g. if they are unmapped, etc.).

No. You can just remember the return address in an array, and when reporting another bug consult that array.

E.g. remember, say, last ten return addresses into array and just lookup there for given caller PC? This sounds reasonable for me.

I would say remember all, and bail out if there are more than 100 different PCs (in which case running further is insane).

I would say remember all, and bail out if there are more than 100 different PCs (in which case running further is insane).

Hm but linear scan through a 100-element array would be slow.

I would say remember all, and bail out if there are more than 100 different PCs (in which case running further is insane).

Hm but linear scan through a 100-element array would be slow.

I think we can use less threshold value.
Another issue is races on shared array. Should we use mutex or perhaps it's OK to sacrifice a bit of accuracy here?

I hope atomic counter will be enough.

Ok, with discussed approach we don't need changes in LLVM part, only in compiler-rt. So, abandoning this revision, let's move further discussion to compiler-rt part (http://reviews.llvm.org/D15080).

m.ostapenko abandoned this revision.Dec 4 2015, 8:36 AM