This section describes some known limitations when using discover.
The discover utility can only instrument code that has been described in Instrumenting a Binary . Uninstrumented 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. If a function is not instrumented, false positive error messages might be emitted, either for the function, its callers, or its callees. Additionally, some errors might not be diagnosed in uninstrumented functions.
The discover utility cannot instrument assembly language modules or functions that contain asm statements or .il templates.
Furthermore, the Oracle Developer Studio 12.6 C++ runtime libraries do not contain annotation data because they were not compiled with an Oracle Developer Studio compiler.
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. Because some source code statements do not have associated machine instructions, discover might not seem to 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 because the memory was not initialized. However, an optimizing compiler will detect that the variable i is not used, so it will not generate the code for the statement reading from memory and assigning to i. In this case, discover will not report uninitialized memory usage (UMR).
Compiler-generated code is not predictable. 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 might not apply to code generated at the –O4 optimization level.
Binaries compiled with the –xlinkopt flag are incompatible with discover.
System libraries are preinstalled with the operating system and cannot be recompiled for instrumentation. The discover utility 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.
The discover utility 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 with the standard functions (for example, pool allocation management implemented with malloc()), then discover might not guarantee to correctly report leaks or access to freed memory.
The discover utility 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 signaltstack(2) function is not supported.