Pointer Checker feature in Intel® Parallel Studio XE 2013: How is it different from Static Analysis, Intel® Inspector XE, Mudflap etc?

The Pointer Checker is a key "new" feature of the Intel® Parallel Studio XE 2013 product release compared to Static Security Analysis (SSA), Mudflap or the Intel® Inspector XE product. In a nutshell, the scope of Pointer Checker is in the detection of out-of-bounds pointer accesses including dangling pointers. The Intel® Inspector XE 2013 (including Static Analysis) is broader in scope and provides a more complete user environment. The table below summarizes the key differences:

FeatureDifferentiation
Pointer Checker in Intel® Parallel Studio XE 2013
  • Analysis Type: Dynamic Run Time Analysis and Protection.
  • Scope: Restricted to the detection of out-of-bounds (OOB) pointer accesses (buffer overflows and overruns) including dangling pointers in stack and heap. Pointer Checker detects OOB violations by keeping track of the bounds information and the object pointed to, without resorting to heuristics. Due to this, OOB violations reported generally turn out to be true positives.
  • Enabled via compile time switches and implemented in a Run Time Library linked automatically during link phase. There is no change to structure layout or ABI
  • Provides checking of all standard RTL functions through corresponding wrapper RTL functions library.
  • Provides “intrinsics” for bounds manipulation. Ideal for the user to write  wrappers for Runtime Library Functions (RTL).
    • Example: custom memory allocators
  • Provides User API to control finding and reporting of OOB violations which includes break point trap for debugging the violation.
  • Pointer Checker can be enabled on a single file or a group of files or the entire application. Both enabled and non-enabled code can co-exist.
  • Less false positives due to real time checks.
  • Recommended for use in application debugging and testing due to perfomance overhead resulting from bounds checking.
Static Analysis in Intel® Parallel Studio XE 2013
  • Analysis Type: Static Analysis of source code.
  • Scope: Broader in scope than Pointer Checker and finds a wide range of errors causing the application to malfunction. Detects buffer overflows and incorrect pointer usage in addition to memory leaks and other program errors including misuse of program constructs. Due to static analysis, the actual content pointed to by the pointer could be different at runtime and therefore can lead to false positives.
  • Unlike dynamic analysis, examines all possible execution paths, not just those provoked by the chosen workload.
  • Intel® Inspector XE 2013 is required to view the results, navigate and fix issues.
  • Large number of false positives possible and results are often inconclusive due to the nature of analysis.
Intel® Inspector XE 2013
  • Analysis Type:  Dynamic Run Time Analysis
  • Scope: Broader in scope than Pointer Checker and provides a more complete user environment. Detects buffer overflows and dangling pointers like Pointer Checker. In addition, it can also detect memory leaks, resource leaks and use of uninitialized memory.
  • Uses dynamic runtime binary instrumentation.
  • Provides a more complete user environment for displaying, navigating and managing results with a GUI and CLI (command line interface) and like Pointer Checker does allow break on the problem location in debugger.
  • Inspector XE can determine valid/invalid stack accesses but unlike Pointer Checker, has no knowledge of the object pointed to or the bounds information and therefore uses heuristics and hence uses extra "guard zones" to mitigate the problem.
  • Does not provide any “intrinsics” for pointer bounds manipulation but does allow API to annotate user allocators.
  • Less false positives due to real time checks.
Mudflap
  • Analysis Type: Dynamic Run Time Analysis and Protection.
  • Scope: Detects buffer overflows, overruns and dangling pointers.
  • Enabled via compile time switches and implemented in a Run Time Library which is not automatically linked during link phase and needs to be specified by the user.
  • Library interoperability issues with Mudflap instrumentation possible, depending on the application.
  • Does not work with DSOs.
  • Does not provide any “intrinsics” for pointer bounds manipulation.
  • Violation messages could be tricky to decode at first.
  • Less false positives due to real time checks.
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione