Many programs rely on dynamically-allocated memory, using features such as:
malloc, valloc, alloca (C/C++)
new (C++)
Stack local variables (Fortran)
MALLOC, MALLOC64 (Fortran)
You must take care to ensure that a program does not rely on the initial contents of dynamically allocated memory unless the memory allocation method is explicitly documented as setting an initial value. For example, compare the descriptions of calloc and malloc in the man page for malloc(3C).
Occasionally, a program that uses dynamically allocated memory might appear to work correctly when run alone, but might fail when run with performance data collection enabled. Symptoms might include unexpected floating‐point behavior, segmentation faults, or application-specific error messages.
Such behavior might occur if the uninitialized memory is, by chance, set to a benign value when the application is run alone but is set to a different value when the application is run in conjunction with the performance data collection tools. In such cases, the performance tools are not at fault. Any application that relies on the contents of dynamically allocated memory has a latent bug: an operating system is at liberty to provide any content whatsoever in dynamically allocated memory unless explicitly documented otherwise. Even if an operating system happens to always set dynamically allocated memory to a certain value today, such latent bugs might cause unexpected behavior with a later revision of the operating system, or if the program is ported to a different operating system in the future.
The following tools may help in finding such latent bugs:
Code Analyzer, a Oracle Solaris Studio tool which when used with the compilers and other tools can show the following:
Code Analyzer can show results of static code checking, which is performed when you compile your application with the Oracle Solaris Studio C or C++ compiler and specify the –xanalyze=code option.
Code Analyzer can show results of dynamic memory access checking, which is performed when you instrument your binary with discover using the–a option, and then run the instrumented binary to generate data.
For more information, see Oracle Solaris Studio 12.4: Code Analyzer User’s Guide
f95 -xcheck=init_local
For more information, see the Oracle Solaris Studio 12.4: Fortran User’s Guide or the f95(1) man page.
lint utility
For more information, see the Oracle Solaris Studio 12.4: C User’s Guide or the lint(1) man page.
Runtime checking under dbx
For more information, see the Oracle Solaris Studio 12.4: Debugging a Program With dbx manual or the dbx(1) man page.