This is an archive of the discontinued LLVM Phabricator instance.

[UBSan] Add silence_unsigned_overflow flag.
ClosedPublic

Authored by morehouse on Jun 27 2018, 10:26 AM.

Details

Summary

Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO
reports. This feature, combined with
-fsanitize-recover=unsigned-integer-overflow, is useful for providing
fuzzing signal without the excessive log output.

Helps with https://github.com/google/oss-fuzz/issues/910.

Diff Detail

Event Timeline

morehouse created this revision.Jun 27 2018, 10:26 AM
vsk accepted this revision.Jun 27 2018, 11:04 AM
vsk added a subscriber: vsk.

LGTM, thanks! Just a small nitpick inline.

Also, if you have the time, please document this in clang/docs/UndefinedBehaviorSanitizer.rst.

compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
3 ↗(On Diff #153120)

You can just pass the --allow-empty flag to FileCheck instead of adding the printf.

This revision is now accepted and ready to land.Jun 27 2018, 11:04 AM
  • Remove unnecesary printf in test.
  • Update documentation.
morehouse marked an inline comment as done.Jun 27 2018, 11:27 AM
This revision was automatically updated to reflect the committed changes.
Herald added a subscriber: Restricted Project. · View Herald TranscriptJun 27 2018, 11:29 AM

Why create yet another way to disable the printing of warnings?
Why not use the suppressions mechanism which is already there?

Thank you,
Filipe

vsk added a comment.Jun 29 2018, 9:13 AM

Why create yet another way to disable the printing of warnings?
Why not use the suppressions mechanism which is already there?

Thank you,
Filipe

That's a great question. Would that work with stripped binaries or binaries without debug info?

@kcc, @Dor1s: Did we previously consider using suppressions to silence UIO for OSS-Fuzz?

Would not suppression kill the fuzzing signal as well?

Would not suppression kill the fuzzing signal as well?

I don't think runtime suppressions would?

Right, I got them confused with blacklist.

(sorry for the delayed response, was OOO for a while) Good point regarding suppressions. I don't think we've considered using it.

Why not use the suppressions mechanism which is already there?

To circle back, @kcc mentioned offline that the existing suppressions mechanism would incur overhead from repeated searches through the suppression list, which is undesirable for fuzzing.