调试艺术：GDB、DDD与Eclipse实战指南

需积分: 9 177 浏览量更新于2024-07-24 收藏 5.38MB PDF 举报

"《THE ART OF DEBUGGING》是一本由Norman Matloff和Peter Jay Salzman合著的专业技术书籍，专注于介绍调试编程的艺术，特别是在使用GDB、DDD（数据探测与开发）以及Eclipse等工具时。这本书的主题深入探讨了在软件开发过程中遇到问题时，如何有效地进行故障排除和代码调试，旨在帮助读者提升解决复杂编程挑战的能力。书中详细讲解了GDB，这是一个强大的交互式命令行调试器，它允许开发者逐步执行代码、检查变量值、设置断点以及跟踪程序执行流程。作者强调了实践的重要性，通过实例展示如何在实际项目中应用GDB进行调试，确保读者不仅理论知识扎实，也能熟练运用到实际工作场景。 DDD（Data Display Debugger）是另一种关键的调试方法，它强调了观察和理解数据在程序运行过程中的变化，通过可视化的方式帮助开发者定位问题。这本书会教导读者如何利用DDD工具进行细致的数据分析，以揭示隐藏在代码中的问题。 Eclipse作为一个广泛使用的集成开发环境（IDE），也被纳入本书的讨论范畴。作者会指导读者如何在Eclipse中集成和优化调试功能，包括使用内置的调试器以及其他调试插件，以提高工作效率。《THE ART OF DEBUGGING》并非仅仅关注技术层面，它还涵盖了调试策略和思维技巧，帮助读者培养一种系统性的解决问题的方法论。书中提倡的是一种从底层逻辑理解问题，再到高效解决方案的迭代过程，鼓励读者养成良好的调试习惯，避免被劣质代码困扰。这本书适合各个层次的开发者，无论是初学者还是经验丰富的专业人士，都能从中获得宝贵的调试技巧和实践案例，从而提升代码质量和项目的稳定性。通过阅读和实践书中的内容，读者将能更好地理解和掌握在当今IT领域中至关重要的调试艺术。"

The Fundamental Principle of Conﬁrmation

Fixing a buggy program is a process of conﬁrming, one by one, that the

many things you believe to be true about the code actually are true. When

you ﬁnd that one of your assumptions is not true, you have found a clue

to the location (if not the exact nature) of a bug.

Another way of saying this is:

Surprises are good!

When one of the things that you think is true about the program fails to

conﬁrm, you are surprised. But it’s a good surprise, because this discovery

can lead you to the location of a bug.

1.3.2 Of What Value Is a Debugging Tool for the Principle of Conﬁrmation?

The classic debugging technique is to simply add trace code to the program

to print out values of variables as the program executes, using

printf() or

cout statements, for example. You might ask, “Isn’t this enough? Why use a

debugging tool like GDB, DDD, or Eclipse?”

First of all, this approach requires a constant cycle of strategically adding

trace code, recompiling the program, running the program and analyzing

the output of the trace code, removing the trace code after the bug is ﬁxed,

and repeating these steps for each new bug that is discovered. This is highly

time consuming and fatigue making. Most importantly, these actions distract

you from the real task and reduce your ability to focus on the reasoning pro-

cess necessary to ﬁnd the bug.

In contrast, with graphical debugging tools like DDD and Eclipse, all

you have to do in order to examine the value of a variable is move the mouse

pointer over an instance of that variable in the code display, and you are

shown its current value. Why make yourself even wearier than necessary,

forlongerthannecessary,duringanall-night debugging session by doing

this using

printf() statements? Do yourself a favor and reduce the amount

of time you have to spend and the tedium you need to endure by using a

debugging tool.

You also get a lot more from a debugging tool than the ability to look

at variables. In many situations, a debugger can tell you the approximate lo-

cation of a bug. Suppose, for example, that your program bombs or crashes

with a segmentation fault, that is, a memory access error. As you will see in our

sample debugging session later in this chapter, GDB/DDD/Eclipse can im-

mediately tell you the location of the seg fault, which is typically at or near

the location of the bug.

Similarly, a debugger lets you set watchpoints that can tell you at what

point during a run of the program the value of a certain variable reaches a

suspect value or range. This information can be difﬁcult to deduce by look-

ing at the output of calls to

printf().

Some Preliminaries for Beginners and Pros 3

1.3.3 Other Debugging Principles

Start small

At the beginning of the debugging process, you should run your pro-

gram on easy, simple cases. This may not expose all of your bugs, but it

is likely to uncover a few of them. If, for example, your code consists of

a large loop, the easiest bugs to ﬁnd are those that arise on the ﬁrst or

second iteration.

Use a top-down approach

You probably know about using a top-down or modular approach to writ-

ing code: Your main program should not be too long, and it should con-

sist mostly of calls to functions that do substantial work. If one of those

functions is lengthy, you should consider breaking it up, in turn, into

smaller modules.

Not only should you write code in a top-down manner, you should

also debug code from the top down.

For example, suppose your program uses a function

f().Whenyou

step through the code using a debugging tool and encounter a call to

f(), the debugger will give you a choice as to where the next pause in ex-

ecution will occur—either at the ﬁrst line within the function about to

be called or at the statement following the function call. In many cases,

the latter is the better initial choice: You perform the call and then in-

spect the values of variables that depend on the results of the call in or-

der to see whether or not the function worked correctly. If so, then you

will have avoided the time-consuming and needless effort of stepping

through the code inside the function, which was not misbehaving (in

this case).

Use a debugging tool to determine the location of a segmentation fault

The very ﬁrst step you take when a seg fault occurs should be to run

your program within the debugger and reproduce the seg fault. The

debugger will tell you the line of code at which the fault occurred. You

can then get additional useful information by invoking the debugger’s

backtrace facility, which displays the sequence of function calls leading to

the invocation of the function in which the fault occurred.

In some cases it may be difﬁcult to reproduce the seg fault, but if

you have a core ﬁle, you can still do a backtrace to determine the situa-

tion that produced the seg fault. This will be discussed in Chapter

Determine the location of an inﬁnite loop by issuing an interrupt

If you suspect your program has an inﬁnite loop, enter the debugger

and run your program again, letting it execute long enough to enter the

loop. Then use the debugger’s interrupt command to suspend the pro-

gram, and do a backtrace to see what point of the loop body has been

reached and how the program got there. (The program has not been

killed; you can resume execution if you wish.)

Use binary search

You’ve probably seen binary search in the context of sorted lists. Say, for

example, that you have an array

x[] of 500 numbers, arranged in ascend-

4 Chapter 1

ing order, and you wish to determine where to insert a new number, y.

Start by comparing

y to x[250].Ify turns out to be smaller than that ele-

ment, you’d next compare it to

x[125],butify is larger than x[250],then

the next comparison would instead be with

x[375]. In the latter case, if

y is smaller than x[375],youthencompareittox[312], which is halfway

between

x[250] and x[375], and so on. You’d keep cutting your search

space in half at each iteration, and so ﬁnd the insertion point quickly.

This principle can be applied while debugging too. Suppose you

know that the value stored in a certain variable goes bad sometime dur-

ing the ﬁrst 1,000 iterations of a loop. One way that might help you

track down the iteration where the value ﬁrst goes bad is to use a watch-

point, an advanced technique that we will discuss in Section

1.5.3.An-

other approach is to use binary search, in this case in time rather than

in space. You’d ﬁrst check the variable’s value at the 500th iteration; if

it is still all right at that point, you’d next check the value at the 750th

iteration, and so on.

As another example, suppose one of the source ﬁles in your pro-

gram will not even compile. The line of code cited in the compiler mes-

sage generated by a syntax error is sometimes far from the actual loca-

tion of the error, and so you may have trouble determining that loca-

tion. Binary search can help here: You remove (or comment out) one

half of the code in the compilation unit, recompile the remaining code,

and see if the error message persists. If it does, then the error is in that

second half; if the message does not appear, then the error is in the half

that you deleted. Once you determine which half of the code contains

the bug, you further conﬁne the bug to half of that portion, and keep

going until you locate the problem. Of course, you should make a copy

of the original code before starting this process or, better yet, use your

text editor’s undo feature. See Chapter 7 for tips on making good use of

an editor while programming.

1.4 Text-Based vs. GUI-Based Debugging Tools, and a Com-

promise Between Them

The GUIs discussed in this book, DDD and Eclipse, serve as front ends to

GDB for C and C++ and to other debuggers. While the GUIs have eye appeal

and can be more convenient than the text-based GDB, our point of view in

this book will be that text-based and GUI-based debuggers (including IDEs)

are all useful, in different contexts.

1.4.1 Brief Comparison of Interfaces

To quickly get an idea of the differences between text-based and GUI debug-

ging tools, let’s consider a situation that we will use as a running example in

this chapter. The program in the example is insert_sort. It is compiled from a

source ﬁle ins.c, and it performs an insertion sort.

Some Preliminaries for Beginners and Pros 5

剩余279页未读，继续阅读

longslap

粉丝: 0
资源: 12

调试艺术：GDB、DDD与Eclipse实战指南

the art of debugging

The Art of Debugging.pdf

THE ART OF DEBUGGING with GDB, DDD, and Eclipse

The Art of Debugging with GDB, DDD, and Eclipse

The.Art.of.Debugging.with.GDB.DDD.and.Eclipse

The.Art.of.Debugging.with.GDB.DDD.and.Eclipse.pdf

The Art of Assembly Language Programming

The Art&Science of JavaScript.pdf

Art of Java Web Development

The.Art.and.Science.of.JavaScript

最新资源