Purify monitors every memory operation in your program, determining whether it is legal. It keeps track of memory that is not allocated to your program, memory that is allocated but uninitialized, memory that is both allocated and initialized, and memory that has been freed after use but still initialized.
Purify maintains a table to track the status of each byte of memory used by your program. The table contains two bits that represent each byte of memory. The first bit records whether the corresponding byte has been allocated. The second bit records whether the memory has been initialized. Purify uses these two bits to describe four states of memory: red, yellow, green, and blue.
Purify checks each memory operation against the color state of the memory block to determine whether the operation is valid. If the program accesses memory illegally, Purify reports an error.
Red: Purify labels heap memory and stack
memory red initially. This memory is unallocated and uninitialized. Either
it has never been allocated, or it has been allocated and subsequently
freed.
In addition, Purify inserts guard zones around each allocated block
and each statically-allocated data item, in order to detect array bounds
errors. Purify colors these guard zones red, and refers to them as red zones. It is illegal to read, write,
or free red memory because it is not owned by the program.
Yellow: Memory returned by malloc or new is yellow. This memory has been allocated so the program owns it, but it is uninitialized. You can write yellow memory, or free it if it is allocated by malloc, but it is illegal to read it because it is uninitialized. Purify sets stack frames to yellow upon function entry.
Green: When you write to yellow memory, Purify labels it green. This means that the memory is allocated and initialized. It is legal to read or write green memory, or free it if it was allocated by malloc or new. Purify initializes the data and bss sections of memory to green.
Blue: When you free memory after it is initialized and used, Purify labels it blue. This means that the memory is initialized, but is no longer valid for access. It is illegal to read, write or free blue memory.
Since Purify keeps track of memory at the byte level, it catches all memory access errors. For example, it reports an uninitialized memory read (UMR) if an int or long (4 bytes) is read from a location previously initialized by storing a short (2 bytes).
In addition to detecting access errors in dynamic memory, Purify detects references beyond the boundaries of data in global variables and static variables, that is, data allocated statically at link-time as opposed to dynamically at run time.
Here is an example of data that is handled by the static checking feature:
int array[10];
main() {
array[11] = 1;
}
In this example, Purify reports an array bounds write (ABW) error at the assignment to array[11] because it is 4 bytes beyond the end of the array.
Purify inserts red guard zones around each variable in your program's static-data area. If the program attempts to read from or write to one of these guard zones, Purify reports an array bounds error (ABR or ABW).
Purify inserts guard zones into the data section only if all data references are to known data variables. If Purify finds a data reference that is relative to the start of the data section as opposed to a known data variable, Purify is unable to determine which variable the reference involves. In this case, Purify inserts guard zones at the beginning and end of the data section only, not between data variables.
Purify provides several command line static checking options and directives to aid in maximizing the benefits of static checking.
Notes:
Purify does not detect array bounds errors between individual local (stack) variables. On Solaris, Purify inserts guard zones between stack frames, causing stack array bounds read (SBR) and stack array bounds write (SBW) errors on accesses that extend beyond all the local variables in a function. Purify detects accesses beyond the end of the stack (BSR and BSW errors) on all platforms, as well as UMR errors on all stack variables.
Due to the flexibility of manipulating pointers in C and C++ programs, a pointer can accidentally access a legally allocated block of memory that is in fact beyond the block that you are attempting to access. In this case, Purify does not signal illegal memory access errors because the memory is properly allocated and initialized. Purify monitors memory accesses and the blocks of memory accessed, not pointer arithmetic. You can use the -static-checking-guardzone option to adjust the size of red zones to find these types of errors.
Purify detects array bounds errors in arrays within C structures only when the access extends beyond the entire structure.