3

I have compiled my application with -fsanitize=undefined option. How can I now test my application for undefined behavior?

Also, how do I run an Asan check? I've compiled my program with -fsanitize=address, and it crashes with the following output:

==4563==Sanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:85 ((allocated < kCallocPoolSize)) != (0) (0, 0)

I've got GCC 4.9.2 on Ubuntu 15.04.

Wandering Fool
  • 2,170
  • 3
  • 18
  • 48
Ilya
  • 728
  • 2
  • 8
  • 22
  • The asan issue as my updated answer says looks like a bug but I could not find a specific one that exactly matches. Your best bet is probably to file a bug report with a specific test case. If you could specify the test case that it fails on in the question it would be more helpful. – Shafik Yaghmour Aug 10 '15 at 02:38
  • *"How can I now test my application for undefined behavior?"* - Asan and UBsan operate on real data. You test your application by running its self tests. If you are following [GNU Coding Standards](https://www.gnu.org/prep/standards/), then `make check` is your next step. – jww May 10 '19 at 17:12
  • Also, @shafik provides an important option for UBsan, `-fno-sanitize-recover`. It is very useful when testing someone else's program when they use a test framework. Often time test frameworks swallow all messages and pretty print OK. That means you miss UBsan's output *`runtime error: ...`*. `-fno-sanitize-recover` causes an `abort()` so the messages are not lost to the test framework. – jww May 10 '19 at 17:24

1 Answers1

7

Unlike a static analysis check, this check will be done at run-time as explained in the following blog entry: GCC Undefined Behavior Sanitizer – ubsan. It will output a runtime error when it detects undefined behavior:

In order to check your program with ubsan, compile and link the program with -fsanitize=undefined option. Such instrumented binaries have to be executed; if ubsan detects any problem, it outputs a “runtime error:” message, and in most cases continues executing the program. There is a possibility of making these diagnostic messages abort — just use the option -fno-sanitize-recover.

And we can see an example from there:

int main() {
    int i = 23;
    i <<= 32; 
}

when ran using -fsanitize=undefined will output (see it live):

runtime error: shift exponent 32 is too large for 32-bit type 'int'

GCC documents this option in their Options for Debugging Your Program or GCC section and it says:

Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector. Various computations are instrumented to detect undefined behavior at runtime.

As for the asan issue this address-sanitizer document gives you an example and the expected results. Perhaps your case it related to this gcc bug.

szotsaki
  • 684
  • 7
  • 16
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • This sample works fine, but if my application is concerned, UBSan outputs nothing. Also, I somewhy have to force link it (-lubsan) for my app, while it is not needed for your sample... – Ilya Aug 10 '15 at 08:13
  • @Ilya have you tried inserting code that has known undefined behavior such as the sample above to see if at least that is flagged? If not, it sounds like a distribution issue or an install issue but that starts getting far away from the original question of *How can I now test my application for undefined behavior?*. A quick scan online comes up with nothing obvious. – Shafik Yaghmour Aug 10 '15 at 12:02
  • Well, I have found a way of successful compilation without -lubsan. Now I use -fsanitize=undefined on linking, not on compilation. However, even obvious problems aren't reported (like int i=23; i <<= 32;). My app has a GUI; may this be a problem? – Ilya Aug 12 '15 at 07:51
  • @Ilya: If you don't *compile* with `-fsanitize=undefined`, no calls to libubsan functions appear in the compiler output, so it links fine if you omit `-lubsan`. But of course then it's not doing any sanitizing. Maybe your sample worked without `-lubsan` because there were no places where it inserted runtime UB checks. – Peter Cordes Nov 02 '17 at 13:17