C毕业设计外文翻译

1、fixing memory problemsthis chapter is about finding bugs in c/c+ programs with the help of a memorydebugger. a memory debugger is a runtime tool designed to trace and detect bugsin c/c+ memory management and access. it does not replace a general debugger.in the following sections, we will describe t

2、he memory access bugs that typicallyoccur in c/c+ programs, introduce memory debuggers, and show with two exampleshow these tools find bugs. we will then show how to run memory and sourcecode debuggers together, how to deal with unwanted error messages by writing asuppression file, and what restrict

3、ions need to be considered.4.1 memory management in c/c+ powerful but dangerousthe c/c+ language is able to manage memory resources, and can access memorydirectly through pointers. efficient memory handling and “programming close to thehardware” are reasons why c/c+ replaced assembly language in the

4、 implementationof large software projects such as operating systems, where performance andlow overhead play a major role. the allocation of dynamic memory (also known asheap memory) in c/c+ is under the control of the programmer. new memory isallocated with functions such as malloc() and various for

5、ms of the operator new.unused memory is returned with free() or delete.the memory handling in c/c+ gives a large degree of freedom, control, andperformance, but comes at a high price: the memory access is a frequent source ofbugs. the most frequent sources of memory access bugs are memory leaks, inc

6、orrectuse of memory management, buffer overruns, and reading uninitialized memory.3334 4 fixing memory problems4.1.1 memory leaksmemory leaks are data structures that are allocated at runtime, but not deallocatedonce they are no longer needed in the program. if the leaks are frequent or large,eventu

7、ally all available main memory in your computer will be consumed. the programwill first slow down, as the computer starts swapping pages to virtual memory,and then fail with an out-of-memory error. finding leaks with a general debugger isdifficult because there is no obvious faulty statement. the bu

8、g is that a statement ismissing or not called.4.1.2 incorrect use of memory managementa whole class of bugs is associated with incorrect calls to memory management:freeing a block of memory more than once, accessing memory after freeing it,or freeing a block that was never allocated. also belonging

9、to this class is usingdelete instead of delete for c+ array deallocation, as well as usingmalloc() together with delete, and using new together with free().4.1.3 buffer overrunsbuffer overruns are bugs where memory outside of the allocated boundaries is overwritten,or corrupted. buffer overruns can

10、occur for global variables, local variableson the stack, and dynamic variables that were allocated on the heap with memorymanagement.one nasty artifact of memory corruption is that the bug may not become visibleat the statement where the memory is overwritten. only later, another statement inthe pro

11、gram will access this memory location. because the memory location has anillegal value, the program can behave incorrectly in a number of ways: the programmay compute a wrong result, or, if the illegal value is in a pointer, the program willtry to access protected memory and crash. if a function poi

12、nter variable is overwritten,the program will do a jump and try to execute data as program code. thekey point is that there may be no strict relation between the statement causing thememory corruption and the statement triggering the visible bug.4.1.4 uninitialized memory bugsreading uninitialized m

13、emory can occur because c/c+ allows creation of variableswithout an initial value. the programmer is fully responsible to initializeall global and local variables, either through assignment statements or through the4.2 memory debuggers to the rescue 35various c+ constructors. the memory allocation f

14、unction malloc() and operatornew also do not initialize or zero out the allocated memory blocks. uninitializedvariables will contain unpredictable values.4.2 memory debuggers to the rescuethe above categories of memory access bugs created a need for adequate debuggingtools. finding bugs related to l

15、eaked, corrupted, or uninitialized memory witha conventional debugger such as gdb turned out to be unproductive. to deal withmemory leaks in large software projects, many programmers came up with the sameidea. they created memory management functions/operators with special instrumentationto track wh

16、ere a memory block was allocated, and if each block wasproperly deallocated at the end of the program.since everybody had the same memory bugs in their c/c+ programs, and sinceeverybody improvised with custom instrumentation to track down at least some ofthese bugs, a market for a tool called memory

17、 debugger was created. the most wellknowntool is purify, released in 1991 by pure software. purifys name has sincebecome synonymous with memory debugging. there is also insure+, valgrind, andboundschecker, among others. see the tools appendix b.4 starting on page 198 forreferences and the survey in

18、luecke06 for a comparison of features.memory debuggers do detailed bookkeeping of all allocated/deallocated dynamicmemory. they also intercept and check access to dynamic memory. somememory debuggers can check access to local variables on the stack and statically allocatedmemory. purify and boundsch

19、ecker do this by object code instrumentationat program link time, insure+ uses source code instrumentation, and valgrind executesthe program on a virtual machine and monitors all memory transactions. thecode instrumentation allows the tools to pinpoint the source code statement where amemory bug occ

20、urred.the following bugs are detectable by a memory debugger: memory leaks accessing memory that was already freed freeing the same memory location more than once freeing memory that was never allocated mixing c malloc()/free()with c+ new/delete using delete instead of delete for arrays array out-of

21、-bound errors accessing memory that was never allocated uninitialized memory read null pointer read or writewe will show in the next section how to attach a memory debugger to your program,and how the tool finds and reports bugs.36 4 fixing memory problems4.3 example 1: detecting memory access error

22、sour first example is a program that allocates an array in dynamic memory, accessesan element outside the final array element, reads an uninitialized array element, andfinally forgets to deallocate the array. we use the public domain tool valgrind onlinux as the memory debugger, and demonstrate how

23、the tool automatically detectsthese bugs. this is the code of our program main1.c:1 /* main1.c */2 #include 3 int main(int argc, char* argv) 4 const int size=100;5 int n, sum=0;6 int* a = (int*)malloc( sizeof(int)*size );78 for (n=size; n0; n-) /* walk through a100.a1 */9 an = n; /* error: a100 inva

24、lid write*/10 for (n=0;n gcc -g main1.c valgrind -tool=memcheck -leak-check=yes ./a.outin the following sections we go through the error list reported by valgrind.4.3.1 detecting an invalid write accessthe first and perhaps most severe error is a buffer overrun: the accidental writeaccess to array e

25、lement a100. because the array has only 100 elements, thehighest valid index is 99. a100 points to unallocated memory that is locatedjust after the memory allocated for array a. valgrind thus reports an “invalid write”error:=11323= invalid write of size 4=11323= at 0x8048518: main (main1.c:9)=11323=

26、 address 0x1bb261b8 is 0 bytes after a block=11323= of size 400 allocd=11323= at 0x1b903f40: malloc=11323= (in /usr/lib/valgrind/vgpreload_memcheck.so)=11323= by 0x80484f2: main (main1.c:6)the string =11323= refers to the process id and is useful when valgrind ischecking multiple processes 1. the im

27、portant piece of information is that an invalid1 valgrind will, per default, check only the first (parent) process that has been invoked. use option-trace-children=yes to check all child processes as well.4.3 example 1: detecting memory access errors 37write occurs in line 9 of main1.c. there is als

28、o additional information revealingthe address of the closest allocated memory block and how it was allocated. thememory debugger guesses that the invalid write in line 9 is related to this memoryblock. the guess is correct because both belong to the same array a.note that valgrind is able to catch a

29、n out-of-array-bounds errors only when thearray is allocated as dynamic memory with malloc() or new. this is the case inthe example with the statement in line 6:6 int* a = (int*)malloc( sizeof(int)*size );if the example were instead written as int asize in line 6, then a would bea local variable loc

30、ated on the stack and not on the heap. it turns out that valgrinddoes not detect such an error but purify is able to catch it. this shows that not allmemory debuggers will report exactly the same errors.修正内存问题本章是关于利用内存bug调试器的帮助，来发现c或c+程序中的bug。内存调试器是在c或c+程序管理或存储时用于追踪和发现bug的运行时工具。它不能取代一个正规的调试器。在一下的章节，

31、我们将描述几个代表性的在c或c+程序中处理的内容bug，介绍内容调试器，并且介绍两个内存如何发现bug的例子。我们然后将演示如何使内存与编码调试器一起运行，怎么去处理不需要的错误信息通过写文件，需要去考虑程序需要的限制。4.1 内存管理在c或c+中强健但是危险c或c+语言能够管理内存资源，并且通过指针直接读取内存。高效的内存处理和“直接控制硬件”是规划大型例如操作系统的软件工程取代汇编语言的原因，高性能和低限制是它作为一个重要角色的原因。动态内存的分配（众所周知的堆内存）在c或c+中是在程序员的控制之下的。新内存被分配担任起例如malloc（）和各种有程序员构成的新的指针。不被使用的内存被fr

32、ee（）或delete回收。4.1.1 内存泄漏内存泄漏是在运行时的内存分配结构，但是它们只需要我们分配一次，我们却分配了多次。如果内存泄漏经常发生或者十分巨大，最后你电脑的主要内存将被耗尽。程序首先会变慢，然后电脑开始使用分页技术虚拟内存，然后以内存溢出错误宣告失败。用普遍的调试器发现内存溢出错误是困难的因为它没有一个明显的错误声明。bug会丢失或不能被声明。4.1.2 错误的内存管理用法一套完整bug集合与错误声明对于内存管理来说：解除一个错误的内存超过一次，在解除以后访问内存，或解除一个从分配过的阻塞内存。用delete代替delete在c+数组中也属于这个类，也可以用malloc（）和

33、delete一起使用，用new和free（）一起使用。4.1.3 缓存溢出缓存溢出内存被重载时超出范围的bug，或损坏。缓存溢出会由属性引起，在堆中的局部变量，通过内存管理分配在栈上的动态变量。在内存中令人讨厌的事是内存重载的时候bug没有被声明。只有在以后，另一个在问题中的声明将存取在内存中。因为内存含有一个不合法的变量，内存会在一下几个方面表现出异常：这个问题得出一个错误的结果，或者如果一个不合法的值在指针上，这个问题将试图存取和保护内存。如果在存取的过程中一个动态指针可变，程序将处理它按照程序代码。键指针不是引起内存溢出和严重问题的关键。4.1.4 非原始内存bug读非原始内存是因为c或

34、c+允许创建变量在没有一个原始值的情况下。程序员有完全的责任给所有的属性和局部变量赋值，也可以通过声明，或各种c+的构造器。内存引导功能malloc（）和操作new也不能够定义变量或者是内存为空。未定义的变量中包含不稳定的值。4.2 内存调试解决上述问题处理bug需要创建一个强大的bug处理工具。寻找bug与漏洞有关，不完善的，只有普通bug调试器gdb内存变得不安全。应付大型软件工程中的系统漏洞，很多程序员都提出了相同的意见。他们建立内存管理机制为一个被分配阻塞内存利用不同的机制，并且确保是否每个阻塞内存在最后都得到了分配。自从每个人在各自的c或c+程序中遇到相同的内存bug，自从每个人用传统的内存处理器追踪到很少的几个bug，一系列叫内存调试器的工具诞生了。最总所周知的是purify，在1991年被pure软件公司发布。purify一直被用于一些同类的内存调试器。也有insure+，valgrind，也有boundschecker，除此之外的一些其他同类工具。内存调试器作用于所有被动态分配的内存。他们同样拦截和检查分配过的内存。一些内存调试器能够检查一些被分配在栈上的局部变量和被分配过的内存。