Debugging by Thinking

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

PC-lint,

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

use

PC-lint

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

14.6.1

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

occurs.

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

14.6.2

Insure++

Insure+,

is a product of ParaSoft. It is available on Windows

TM,

as well as

on popular versions of UNIX

TM

and Linux

TM.

14.6.2. I Features

Insure++

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

Insure++

detects the following memory-leak problems:

9 Freeing blocks of memory that contain pointers to other blocks of

memory

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

pointers

Insure++

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