This section describes some known limitations when using discover.
The discover utility can instrument only code that has been prepared as described in Prepare Binaries 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.
The discover utility cannot instrument assembly language modules or functions that contain asm statements or .il templates.
Furthermore, the Oracle Solaris Studio 12.4 C++ runtime libraries do not contain annotation data because they were not compiled with an Oracle Solaris Studio compiler. If you want to use discover with a program built with the C++ compiler using the –std=c++11 option, discover will not catch UMR or PIR errors.
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 note 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.
The discover tool cannot detect UMR or PIR errors if the program is built with the compilers using the C++11 standard options.
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.
Because of the algorithms that discover uses to detect array bounds, it is not possible to detect automatic out of bounds access errors for static and automatic (local) arrays. However, discover can detect static array-out-of-bounds access errors. Errors can be detected for dynamically allocated arrays.