-fsanitize

Purpose

Controls whether the compiler adds runtime checks for various forms of undefined or suspicious behaviors.

Syntax

Note: address and undefined are group check options. There are additional suboptions for individual checks. Note that the group options cannot enable all individual checks in batch. Find all suboptions and option usage in Clang options.

Default

None.

Usage

Use -fsanitize=address to enable AddressSanitizer (ASan), a compiler and runtime technology designed to quickly detect memory errors. Use -fsanitize=undefined to enable UndefinedBehaviorSanitizer (UBSan), a fast undefined behavior detector that modifies the program at compile time to catch various kinds of undefined behavior during program execution. To use UBSan with minimal runtime, which is known as minimal UBSan, specify -fsanitize=undefined -fsanitize-minimal-runtime. Find details of these tools in AddressSanitizer and UndefinedBehaviorSanitizer.

Minimal UBSan is suitable for use in the production environment. However, both ASan and UBsan are debug tools and are not recommended for production use. If you have to use ASan or UBSan in the production environment, it is highly recommended not to enable them on a privileged binary that has suid bit set.

Note: To make ASan symbolize its output, set the value of the ASAN_SYMBOLIZER_PATH environment variable to point to the ibm-llvm-symbolizer tool. Unlike the Clang version of ASan, you cannot symbolize the output using a separate script or by adding the path of ibm-llvm-symbolizer to the $PATH environment variable.

Limitations: In IBM Open XL C/C++ for AIX 17.1.3, the functionality of these tools is almost the same as that of the tools in Clang. However, there are some limitations when using ASan in IBM Open XL C/C++ for AIX 17.1.3:

ASan cannot be used together with the -bmaxdata option when debugging 32-bit XCOFF binaries; otherwise, the compiler might issue an error message. This restriction exists because ASan and large programs might have conflicts in their use of certain memory regions. For details of large programs, refer to Large program support in the AIX documentation.

When you use ASan for shared libraries, it cannot detect memory issues if they exist within a system library function that is called inside a shared library. See the following example:

$ cat main.c

#include <stdlib.h>
#include <string.h>

char func(char *);
int main() {
   char s[] = "34";
   char *p = strdup((const char *)s);
   free(p);
   char t = func(p);
   return t;
}

$cat shared.c
#include<stdio.h>
char func(char *p){
   printf("%s\n", p);
   return 0;
}

Compile the program using the following commands. A wild pointer is passed to the printf system function, which is called within a shared library. As a result, ASan cannot detect the memory issue inside printf.

ibm-clang -fsanitize=address -fPIC -shared -o libtest.a shared.c
ibm-clang -fsanitize=address main.c -L./ -ltest
./a.out ; echo $?
0

The invalid free check of ASan is disabled in IBM Open XL C/C++ for AIX 17.1.3, so ASan cannot detect invalid free types of memory issues. In the following example, the free statement can cause a serious issue, but the problem cannot be detected. A workaround solution is to set environment variable ASAN_OPTIONS=enable_unmalloced_free_check=1 when the sanitized executable is executed.
```
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv) {
  char *x = (char*)malloc(10 * sizeof(char));
  memset(x, 0, 10);
  int res = x[argc];
  free(x + 5);  // By default, this invalid free error cannot be detected
  return res;
}
```

Predefined macros

None.