488 14.6 Dynamic-analysistools
more likely to indicate bugs. Some reports from these tools have such a low
yield of real bugs that you're better off ignoring them. On the other hand,
for those reports that you know have a meaningful possibility of indicating a
real bug, you should investigate them immediately and resolve the problem.
If you're starting a new project and plan to use
decide which of
its messages you will be concerned about, turn them on, and resolve them
frequently. Some projects do a nightly build of their software, and this is an
excellent time to run a static analyzer. First thing in the morning, you can
resolve all of the reports, in addition to any bugs turned up by nightly test-
ing. Don't let a backlog develop. The inevitable result of accumulating a
backlog is that you will turn off the messages and eventually stop using the
tool altogether.
If you're doing maintenance of an existing project and have decided to
at this point in the project life cycle, it's important to schedule
time to resolve all the reports this tool will generate. Once you have decided
which reports you will be concerned about, resolve all of them and follow a
zero-tolerance policy so they don't creep back in.
In either case, it's instructive to keep a record of the percentage of
reports that actually indicate a real defect. Even for the most important
messages, this will still be only a modest fraction of the total. Even if only 5
percent of the messages point to a problem, that could translate to dozens
of defects that weren't being found by your other methods of testing.
14.6 Dynamic-analysis tools
Dynamic analysis
There are several reasons why dynamic analysis may be more effective than
static analysis in diagnosing a bug. Dynamic analysis can include system
and third-party libraries. Source code isn't required. Dynamic analysis only
evaluates code that is executed. This is likely to take less system time than
static analysis. With dynamic analysis, an error is caught right before it
On the other hand, dynamic analysis isn't perfect. Dynamic analysis
only evaluates code that is executed. It won't find defects in code not exer-
cised by your tests. To get the full benefit from a dynamic-analysis tool, you
need a comprehensive test suite in place. You should also have a test cover-
age tool that will enable you to determine whether your test suite actually
exercises all parts of your application.
14.6 Dynamic-analysis tools 489
is a product of ParaSoft. It is available on Windows
as well as
on popular versions of UNIX
and Linux
14.6.2. I Features
detects the following pointer-reference problems:
9 References to null pointers
9 References to uninitialized pointers
9 References to pointers that don't point to valid memory locations
9 Comparison of pointers that point to different memory blocks
9 Attempts to execute functions through pointer references that don't
actually point to functions
detects the following memory-leak problems:
9 Freeing blocks of memory that contain pointers to other blocks of
9 Functions that ignore pointers to storage allocated by a subfunction
and returned as a result
9 Functions that return without fleeing storage pointed to by local
detects the following miscellaneous pointer problems:
9 Freeing a memory block more than once
9 Freeing static memory (global variables)
9 Freeing stack memory (local variables)
9 Applying free or delete to an address that isn't the beginning of an
allocated memory block
9 Applying free or delete to a null or uninitialized pointer
I Chapter 14

Get Debugging by Thinking now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.