Limitations When Using Discover

Only Annotated Code is Instrumented

Discover can instrument only code that has been prepared as described in Binaries Must Be Prepared Correctly. Non-annotated code might come from assembly language code linked into the binary, or from modules compiled with older compilers or operating systems than those listed in that section.

Specifically excluded from preparation are assembly language modules and functions that contain asm statements or .il templates.

Machine Instruction Might Differ From Source Code

Discover operates on machine code. The tool detects errors on machine instructions such as loads and stores, and correlates the errors with the source code. Some source code statements do not have associated machine instructions, so it may appear that Discover did not detect an obvious user error. For example, consider the following C code fragment:

  int *p = (int *)malloc(sizeof(int));
  int i;

  i = *p;  /* compiler may not generate code for this statement */
  printf("Hello World!\n");

  return;

Reading a value stored at the address pointed to by p is a potential user error since the memory was not initialized. However, an optimizing compiler will detect that the variable i is not used, so the code for the statement reading from memory and assigning to i will not be generated. In this case, Discover will not report uninitialized memory usage (UMR).

Compiler Options Affect the Generated Code

Compiler-generated code is not always as you expect it to be. Because the code the compiler generates varies depending on the compiler options you use, including the -On optimization options, the errors reported by Discover might also vary. For example, errors reported in code generated at the -O1 optimization level could disappear for code generated at the -O4 optimization level.

System Libraries Can Affect the Errors Reported

System libraries are preinstalled with the operating system and cannot be recompiled for instrumentation. Discover provides support for the common function from the standard C library (libc.so); that is, Discover knows what memory is accessed or modified by these functions. However, if your application uses other system libraries, you might see false positives in the Discover report. If false positives are reported, you can call the Discover API from your code to eliminate them.

Custom Memory Management Can Affect the Accuracy of the Data

Discover can track heap memory when it is allocated by standard programming language mechanisms like malloc(), calloc(), free(), operator new(), and operator delete().

If your application uses a custom memory management system working on top of the standard functions (for example, pool allocation management implemented with malloc()), then Discover works, but is not guaranteed to correctly report leaks or access to freed memory.

Discover does not support the following memory allocators:

• Custom heap allocators that use brk(2)() or sbrk(2)() system calls directly

• Standard heap management function linked statically into a binary

• Memory allocated from the user code using mmap(2)() and shmget(2)() system calls

The sigaltstack(2)() function is not supported.

Out of Bounds Errors for Static and Automatic Arrays Cannot Be Detected

Because of the algorithms that Discover uses to detect array bounds, it is not possible to detect out of bounds access errors for static and automatic (local) arrays. Errors can be detected only for dynamically allocated arrays.