This is an archive of the discontinued LLVM Phabricator instance.

ubsan: add 'UndefinedBehaviorSanitizer' to messages
Needs ReviewPublic

Authored by ben.boeckel on Oct 6 2014, 11:57 AM.

Details

Reviewers
samsonov
rsmith
Summary

This allows detection of them to be much more accurate since 'runtime error:' and 'note:' are fairly generic.

Diff Detail

Event Timeline

ben.boeckel retitled this revision from to ubsan: add 'UndefinedBehaviorSanitizer' to messages.
ben.boeckel updated this object.
ben.boeckel edited the test plan for this revision. (Show Details)
ben.boeckel added reviewers: rsmith, samsonov.
ben.boeckel added a subscriber: Unknown Object (MLST).
samsonov edited edge metadata.Oct 6 2014, 12:06 PM

Hi Ben!

I think we should improve it in a different way. I think we should either replace "runtime-error" with "undefined-behavior", or be even more specific and print the exact UB kind in bold red letters here ("integer overflow", "misaligned address" etc). Richard, WDYT?

rsmith edited edge metadata.Oct 6 2014, 1:06 PM

I'm fine changing "runtime error" to "undefined behavior". As to listing the kind of undefined behavior, how about following Clang's diagnostic format and adding a [-fsanitize=<kind of UB>] suffix?

ben.boeckel updated this revision to Diff 15956.Nov 8 2014, 9:32 PM
ben.boeckel edited edge metadata.

Updates messages to contain the sanitizer which triggered the message. There's a part which is a little nasty (strcmp() to see if 'bool' or 'enum' is the trigger sanitizer), but can be addressed by patching TypeDescriptor to have a flag for 'bool' (not done here).

I've submitted a parallel patch to GCC here: https://codereview.appspot.com/168380043/.

I'm opposed to this change. The error messages you suggest are occasionaly confusing

UndefinedBehaviorSanitizer function error

or way too redundant

UndefinedBehaviorSanitizer unsigned-integer-overflow error: unsigned integer overflow:

Also, if UBSan is combined with another sanitizer (most notably, ASan), we treat the latter as the "main" tool, and don't mention UBSan in error reports. For instance,
look at the SUMMARY: line that would be emiited in this case:

SUMMARY: AddressSanitizer: undefined-behavior: file.cc:10

I'd prefer to replace generic "runtime error" with generic "undefined-behavior" (or at least make it a common prefix). I also like the idea of specifying the exact -fsanitize= flag that caused the error (what Richard suggests), if that's easily doable.

lib/ubsan/ubsan_handlers.cc
19

It's not allowed to #include system headers into generic sanitizer runtimes.

348

This is wrong, this type of check is also emitted for bool-like types.

In D5629#9, @samsonov wrote:

I'm opposed to this change. The error messages you suggest are occasionaly confusing

UndefinedBehaviorSanitizer function error

or way too redundant

UndefinedBehaviorSanitizer unsigned-integer-overflow error: unsigned integer overflow:

Also, if UBSan is combined with another sanitizer (most notably, ASan), we treat the latter as the "main" tool, and don't mention UBSan in error reports. For instance,
look at the SUMMARY: line that would be emiited in this case:

SUMMARY: AddressSanitizer: undefined-behavior: file.cc:10

The test cases don't specialize for UBSan and UBSan+ASan together and pass, so I don't know that this is accurate (or you're referring to something else).

I'd prefer to replace generic "runtime error" with generic "undefined-behavior" (or at least make it a common prefix). I also like the idea of specifying the exact -fsanitize= flag that caused the error (what Richard suggests), if that's easily doable.

The string is the sanitize flag which caused the error, just placed next to "UndefinedBehaviorSanitizer" like it is with AddressSanitizer. I'm not opposed to putting it in parentheses or brackets to distinguish it, but ASan doesn't do this (though ASan is also just ASan and not a group of other sanitizers):

ERROR: AddressSanitizer heap-use-after-free on address

Error messages could certainly be cleaned up to be have less duplication as well.

lib/ubsan/ubsan_handlers.cc
19

OK. I'll make the TypeDescriptor aware of bool then which would make this unnecessary.

348

Such as? Would 'enum' not be accurate for that? In any case, rsmith did mention (at the WG21 meeting) that TypeDescriptor should probably grow support for 'bool' since its sizeof() is likely 8 and therefore indistinguishable that way.