Features
|
Category
|
Error
|
Insure++
|
Purify
|
Memory Corruption
|
Dynamically allocated memory
|
Yes
|
Note 2
|
Note 1
|
STATIC/global memory
|
Yes
|
Yes
|
|
Stack/local memory
|
Yes
|
Yes
|
|
Shared memory
|
Yes
|
No
|
|
Uninitialized memory
|
Yes
|
Yes
|
Memory Leaks
|
Dynamic memory losses
|
Yes
|
Note 3
|
|
Detects exact line where error occurs
|
Yes
|
No
|
|
Graphically display memory usage
|
Yes
|
No
|
Memory Allocation Errors
|
Allocating and freeing dynamic memory
|
Yes
|
Note 4
|
Variable Definition Conflicts
|
Incompatible variable declarations
|
Yes
|
No
|
I/O Errors
|
Mismatched argument types
|
Yes
|
No
|
|
Invalid parameters
|
Yes
|
No
|
|
Errors returned by library calls
|
Yes
|
No
|
Pointer Errors
|
Uninitialized
|
Yes
|
Yes
|
|
NULL
|
Yes
|
Yes
|
|
Dangling
|
Yes
|
Yes
|
|
Operations on unrelated pointers
|
Yes
|
No
|
Library Errors
|
Mismatched argument types
|
Yes
|
No
|
|
Mismatched function declarations
|
Yes
|
No
|
|
Invalid parameters
|
Yes
|
Note 5
|
Program Optimization
|
Highlight bottlenecks by showing access
|
Yes
|
No
|
|
Algorithm tuning with data access patterns
|
Yes
|
No
|
Program Understanding
|
Correlates memory access with code execution
|
Yes
|
No
|
|
Displays memory fragmentation
|
Yes
|
No
|
|
Displays memory utilization and access patterns
|
Yes
|
No
|
|
Computes variable values and ranges
|
Yes
|
No
|
Coverage Analysis
|
Detects untested code
|
Yes
|
Yes
|
|
Counts how often each line of code is executed
|
Yes
|
Yes
|
Platform Availability
|
Platform
|
Insure++
|
Purify
|
DEC Alpha (Digital Unix)
|
Yes
|
No
|
HP 9000/7xx
|
Yes
|
Yes
|
IBM RS/6000
|
Yes
|
No
|
Linux x86
|
Yes
|
No
|
SCO Unix x86
|
Yes
|
No
|
SGI
|
Yes
|
Yes
|
Sun/Sparc (SunOS)
|
Yes
|
Yes
|
Sun/Sparc (Solaris)
|
Yes
|
Yes
|
1) These memory corruption errors occur due to reading or writing
beyond the valid areas of global, local, shared, and dynamically
allocated objects.
2)
Purify builds a band of unused memory to create a narrow
"fence" around each malloc'd area. This method has only a
statistical chance of catching a small class of memory errors. If an
error hops the "fence" it escapes to raise havoc later on.
The fence technique catches some errors, which may not be good enough.
Insure++ has perfect knowledge of all data, pointer, and memory
operations, because it studies the source code. So Insure++
captures every memory error, for every type of memory - global (static),
local (stack), dynamically allocated (heap) and even shared.
3)
Purify uses a heuristic algorithm to catch some memory leaks. If it
catches a leak, Purify shows only where the memory was malloc'd, not
where it was lost.
Insure++, with its access to the source code, not only detects
every memory leak, but also pinpoints the exact statement which caused
the leak, immediately when the leak occurs.
4)
Purify keeps the most recent mallocs and frees in a fixed size list.
All errors related to older operations, pushed off the list by more
recent mallocs and frees, will escape undetected. Statistically, the
fixed size list approach will catch some errors. For your customers,
this may not be good enough.
Insure++ has perfect knowledge of memory and variable usage, and
perfect recall of all memory operations. So it captures EVERY error,
no matter how many times malloc and free are called.
5)
Purify checks the arguments to only certain "well-known"
C functions. The only return value which can be checked is from malloc.
Checking malloc is good, but leaving all other functions unchecked may
not be good enough.
Insure++ has a built-in library with thousands of interfaces to
common libraries, allowing full checking on parameters and return values.
Using Insure++'s innovative Total Quality Software tm
(TQS tm) technology, you have complete control over what
checks are done, and can even perform complicated parameter checking on
your own libraries and functions.
|