alp-apA-other-development-tools(2).pdf

Other Development Tools

D EVELOPING CORRECT , FAST C OR C++ GNU/L INUX PROGRAMS requires more

than just understanding the GNU/Linux operating system and its system calls. In this

appendix, we discuss development tools to find runtime errors such as illegal use of

dynamically allocated memory and to determine which parts of a program are taking

most of the execution time. Analyzing a program’s source code can reveal some of this

information; by using these runtime tools and actually executing the program, you can

find out much more.

A.1 Static Program Analysis

Some programming errors can be detected using static analysis tools that analyze the

program’s source code. If you invoke GCC with -Wall and -pedantic , the compiler

issues warnings about risky or possibly erroneous programming constructions. By

eliminating such constructions, you’ll reduce the risk of program bugs, and you’ll find

it easier to compile your programs on different GNU/Linux variants and even on

other operating systems.

260 Appendix A Other Development Tools

Using various command options, you can cause GCC to issue warnings about

many different types of questionable programming constructs.The -Wall option

enables most of these checks. For example, the compiler will produce a warning

about a comment that begins within another comment, about an incorrect return type

specified for main , and about a non void function omitting a return statement. If you

specify the -pedantic option, GCC emits warnings demanded by strict ANSI C and

ISO C++ compliance. For example, use of the GNU asm extension causes a warning

using this option. A few GNU extensions, such as using alternate keywords beginning

with __ (two underscores), will not trigger warning messages. Although the GCC

info pages deprecate use of this option, we recommend that you use it anyway and

avoid most GNU language extensions because GCC extensions tend to change

through time and frequently interact poorly with code optimization.

Listing A.1 ( hello.c ) Hello World Program

main ()

{

printf (“Hello, world.\n”);

}

Consider compiling the “Hello World” program shown in Listing A.1.Though GCC

compiles the program without complaint, the source code does not obey ANSI C

rules. If you enable warnings by compiling with the -Wall -pedantic , GCC reveals

three questionable constructs.

% gcc -Wall -pedantic hello.c

hello.c:2: warning: return type defaults to ‘int’

hello.c: In function ‘main’:

hello.c:3: warning: implicit declaration of function ‘printf’

hello.c:4: warning: control reaches end of non-void function

These warnings indicate that the following problems occurred:

n The return type for main was not specified.

n The function printf is implicitly declared because <stdio.h> is not included.

n The function, implicitly declared to return an int , actually returns no value.

Analyzing a program’s source code cannot find all programming mistakes and ineffi-

ciencies. In the next section, we present four tools to find mistakes in using dynami-

cally allocated memory. In the subsequent section, we show how to analyze the

program’s execution time using the gprof profiler.

A.2 Finding Dynamic Memory Errors

261

A.2 Finding Dynamic Memory Errors

When writing a program, you frequently can’t know how much memory the program

will need when it runs. For example, a line read from a file at runtime might have any

finite length. C and C++ programs use malloc , free , and their variants to dynamically

allocate memory while the program is running.The rules for dynamic memory use

include these:

n The number of allocation calls (calls to malloc ) must exactly match the number

of deallocation calls (calls to free ).

n Reads and writes to the allocated memory must occur within the memory, not

outside its range.

n The allocated memory cannot be used before it is allocated or after it is

deallocated.

Because dynamic memory allocation and deallocation occur at runtime, static program

analysis rarely find violations. Instead, memory-checking tools run the program, col-

lecting data to determine if any of these rules have been violated.The violations a tool

may find include the following:

n Reading from memory before allocating it

n Writing to memory before allocating it

n Reading before the beginning of allocated memory

n Writing before the beginning of allocated memory

n Reading after the end of allocated memory

n Writing after the end of allocated memory

n Reading from memory after its deallocation

n Writing to memory after its deallocation

n Failing to deallocate allocated memory

n Deallocating the same memory twice

n Deallocating memory that is not allocated

It is also useful to warn about requesting an allocation with 0 bytes, which probably

indicates programmer error.

Table A.1 indicates four different tools’ diagnostic capabilities. Unfortunately, no

single tool diagnoses all the memory use errors. Also, no tool claims to detect reading

or writing before allocating memory, but doing so will probably cause a segmentation

fault. Deallocating memory twice will probably also cause a segmentation fault.These

tools diagnose only errors that actually occur while the program is running. If you run

the program with inputs that cause no memory to be allocated, the tools will indicate

no memory errors.To test a program thoroughly, you must run the program using dif-

ferent inputs to ensure that every possible path through the program occurs. Also, you

may use only one tool at a time, so you’ll have to repeat testing with several tools to

get the best error checking.

262 Appendix A Other Development Tools

Table A.1 Capabilities of Dynamic Memory-Checking Tools (X Indicates

Detection, and O Indicates Detection for Some Cases)

Erroneous Behavior

malloc

mtrace ccmalloc Electric

Checking

Fence

Read before allocating memory

Write before allocating memory

Read before beginning of allocation

Write before beginning of allocation

Read after end of allocation

Write after end of allocation

Read after deallocation

Write after deallocation

Failure to deallocate memory

Deallocating memory twice

Deallocating nonallocated memory

Zero-size memory allocation

In the sections that follow, we first describe how to use the more easily used malloc

checking and mtrace , and then ccmalloc and Electric Fence.

A.2.1 A Program to Test Memory Allocation and

Deallocation

We ’ll use the malloc-use program in Listing A.2 to illustrate memory allocation, deal-

location, and use.To begin running it, specify the maximum number of allocated

memory regions as its only command-line argument. For example, malloc-use 12

creates an array A with 12 character pointers that do not point to anything.The

program accepts five different commands:

n To allocate b bytes pointed to by array entry A[i] , enter a i b .The array index i

can be any non-negative number smaller than the command-line argument.The

number of bytes must be non-negative.

n To deallocate memory at array index i , enter d i .

n To read the p th character from the allocated memory at index i (as in A[i][p] ),

enter r i p . Here, p can have an integral value.

n To write a character to the p th position in the allocated memory at index i ,

enter w i p .

n When finished, enter q .

We ’ll present the program’s code later, in Section A.2.7, and illustrate how to use it.

A.2 Finding Dynamic Memory Errors

263

A.2.2 malloc Checking

The memory allocation functions provided by the GNU C library can detect writing

before the beginning of an allocation and deallocating the same allocation twice.

Defining the environment variable MALLOC_CHECK_ to the value 2 causes a program to

halt when such an error is detected. (Note the environment variable’s ending under-

score.) There is no need to recompile the program.

We illustrate diagnosing a write to memory to a position just before the beginning

of an allocation.

% export MALLOC_CHECK_=2

% ./malloc-use 12

Please enter a command: a 0 10

Please enter a command: w 0 -1

Please enter a command: d 0

Aborted (core dumped)

export turns on malloc checking. Specifying the value 2 causes the program to halt as

soon as an error is detected.

Using malloc checking is advantageous because the program need not be recom-

piled, but its capability to diagnose errors is limited. Basically, it checks that the alloca-

tor data structures have not been corrupted.Thus, it can detect double deallocation of

the same allocation. Also, writing just before the beginning of a memory allocation

can usually be detected because the allocator stores the size of each memory allocation

just before the allocated region.Thus, writing just before the allocated memory will

corrupt this number. Unfortunately, consistency checking can occur only when your

program calls allocation routines, not when it accesses memory, so many illegal reads

and writes can occur before an error is detected. In the previous example, the illegal

write was detected only when the allocated memory was deallocated.

A.2.3 Finding Memory Leaks Using mtrace

The mtrace tool helps diagnose the most common error when using dynamic

memory: failure to match allocations and deallocations.There are four steps to using

mtrace , which is available with the GNU C library:

1. Modify the source code to include <mcheck.h> and to invoke mtrace () as soon

as the program starts, at the beginning of main .The call to mtrace turns on

tracking of memory allocations and deallocations.

2. Specify the name of a file to store information about all memory allocations and

deallocations:

% export MALLOC_TRACE=memory.log

3. Run the program. All memory allocations and deallocations are stored in the

logging file.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: