Memory debugging skills: the greatest difficulty in C Language

This article will show you some good memory-related coding practices to keep memory errors under control. Memory errors are the root cause of C and C ++ programming: they are common and have been known to be serious for more than 20 years, but they have never been completely resolved and may seriously affect applications.ProgramAnd few development teams have clearly defined management plans. But the good news is that they are not mysterious. Introduction

Memory Errors in C and C ++ programs are extremely harmful: they are common and may cause serious consequences. Many of the most serious security announcements from the Computer Emergency Response Team (see references) and vendors are caused by simple memory errors. Since the end of 1970s, C programmers have been discussing such errors, but the impact is still very high in 2007. Even worse, many C and C ++ programmers may think that memory errors are uncontrollable and mysterious, and they can only be corrected, cannot be prevented.

But this is not the case. This article will allow you to understand all the features of good memory encoding in a short time:

The importance of correct Memory Management

C and C ++ programs with memory errors may cause various problems. If they leak memory, the running speed will gradually slow down and the operation will eventually stop. If the memory is overwritten, the Operation will become very fragile and vulnerable to attacks by malicious users. The latest security alerts from the famous Morris worm attack in 1988 to Flash Player and other key retail programs are related to buffer overflow: "Most computer security vulnerabilities are buffer overflow ", rosydney Bates wrote in 2004.

Many other general languages (such as Java? Ruby, Haskell, C #, Perl, smalltalk, etc.), each language has many enthusiasts and their respective advantages. However, from a computing point of viewProgramming LanguageThe main advantages over C or C ++ are closely related to ease of memory management. Memory-related programming is so important, and correct application in practice is so difficult, so that it controls all other variables or theories of object-oriented programming languages, functional programming languages, advanced programming languages, declarative programming languages, and other programming languages.

Like a few common errors, memory errors are a hidden hazard: they are hard to reproduce and the symptoms are usually notSource code. For example, whenever and wherever a memory leak occurs, it may be totally unacceptable to the application, and the memory leak is not obvious.

Therefore, for all these reasons, we need to pay special attention to the memory problems of C and C ++ programming. Let's take a look at how to solve these problems. Let's not talk about the language.

Memory Error category

First, do not lose confidence. There are many ways to deal with memory problems. First, we will list all possible problems:

1. Memory leakage

2. misallocation, including a large increase in free () memory and uninitialized references

3. Floating pointer

4. array boundary Violation

This is all types. Even if you migrate data to a C ++ object-oriented language, these types will not change significantly; whether the data is a simple type or a C-language struct or C ++ class, the memory management and reference models in C and C ++ are the same in principle. The vast majority of the following content is the "pure C" language. It is mainly used for exercises to extend to C ++.

Memory leakage

 

Memory leakage occurs when resources are allocated, but it is never recycled. The following is an error-prone model (see Listing 1 ):

Listing 1. Simple potential heap memory loss and buffer coverage

The following is a reference clip: Void F1 (char * explanation) { Char P1; P1 = malloc (100 ); (Void) sprintf (P1, "The F1 error occurred because of '% s '.", Explanation ); Local_log (P1 ); }

Have you seen the problem? Unless local_log () has an unusual response capability to the memory released by free (), each call to F1 will leak 100 bytes. When the memory stick incrementally distributes several megabytes of memory, a single leak is insignificant, but even a small leak will weaken the application after the consecutive operation hours.

In actual C and C ++ programming, this is not enough to affect your use of malloc () or new, the sentence at the beginning of this section mentions that "resource" does not only refer to "Memory", because there are examples similar to the following (see Listing 2 ). File handles may be different from memory blocks, but they must be given the same attention:

Listing 2. Potential heap memory loss from resource error management

The following is a reference clip: Int getkey (char * filename) { File * FP; Int key; Fp = fopen (filename, "R "); Fscanf (FP, "% d", & Key ); Return key; }

The semantics of fopen requires complementary fclose. In the absence of fclose (), when the c Standard cannot specify the occurrence, it is likely that the memory is leaked. Other resources (such as semaphores, network handles, and database connections) are also worth considering.

Memory Allocation Error

Management of misallocation is not very difficult. The following is an example (see listing 3 ):

Listing 3. uninitialized pointer

The following is a reference clip: Void F2 (INT datum) { Int * P2; /* Uh-oh! No one has initialized P2 .*/ * P2 = datum; ... }

The good news about such errors is that they generally have notable results. In Aix, allocation of Uninitialized pointers usually immediately results in a segmentation fault error. It has the advantage that any such errors will be quickly detected; compared with errors that take several months to determine and are hard to reproduce, the cost of detecting such errors is much lower.

Multiple variants exist in this error type. Free () memory is released more frequently than malloc () (see Listing 4 ):

Listing 4. Two wrong Memory releases

 

The following is a reference clip: /* allocate once, free twice. */ void F3 () {< br> char * P; P = malloc (10 ); ... free (p); ... free (p); } /* allocate zero times, free once. */ void F4 () {< br> char * P; /* Note that P remains uninitialized here. */ free (p); }

These errors are usually not very serious. Although the c Standard does not define specific actions in these cases, typical implementations will ignore errors or quickly and clearly mark them; in short, these are security situations.

Floating pointer

Hanging pointers are tricky. When a programmer uses a resource after the memory resources are released, a floating pointer occurs (see listing 5 ):

Listing 5. Floating pointer

The following is a reference clip: void F8 () {< br> struct x * XP; XP = (struct x *) malloc (sizeof (struct X )); XP. Q = 13; ... free (XP); ... /* problem! There's no guarantee that the memory block to which XP Points hasn't been overwritten. */ return XP. q; }

Traditional "Debugging" is difficult to isolate hanging pointers. They are hard to reproduce for the following two obvious reasons:

Even if the range of memory to be released in advance is affectedCodeThe memory usage may still depend on the application or even (in extreme cases) Other execution locations in different processes.

Floating pointers may occur in code that uses memory in a subtle way. The result is that it is difficult to identify the new value as an error even if it exists and is immediately overwritten, and the new value is different from the expected value. Hanging pointers constantly threaten the running status of C or C ++ programs.

Array boundary Violation

Array boundary violation is very dangerous. It is the last major category of memory error management. Let's look back at listing 1. What happens if the length of the explain statement exceeds 80? A: It is unpredictable, but it may be far from a good situation. In particular, C copies a string that is not suitable for the allocation of 100 characters. In any general implementation, the "more than" character will overwrite other data in the memory. The layout of data allocation in the memory is very complex and difficult to reproduce, so no symptoms can be traced back to specific errors at the source code level. These errors usually result in millions of dollars in losses.

Memory programming policy

Diligence and self-discipline can minimize the impact of these mistakes. Next we will introduce several specific steps you can take. My experience in handling them in various organizations is that at least a certain order of magnitude can be used to continuously reduce memory errors.

Encoding Style

 

The encoding style is the most important, and I have never seen any other authors emphasize it. Functions and methods that affect resources (especially memory) must be explicitly interpreted. The following are examples of headers, comments, or names (see Listing 6 ).

Listing 6. source code examples for identifying resources

The following is a reference clip: /******** *... * * Note that any function invoking protected_file_read () * Assumes responsibility eventually to fclose () its * Return value, unless that value is null. * ********/ File * protected_file_read (char * filename) { File * FP; Fp = fopen (filename, "R "); If (FP ){ ... } Else { ... } Return FP; } /******* *... * * Note that the return value of get_message points to * Fixed memory location. Do not free () It; Remember * Make a copy if it must be retained... * ********/ Char * get_message () { Static char this_buffer [400]; ... (Void) sprintf (this_buffer ,...); Return this_buffer; } /******** *... * While this function uses heap memory, and so * Temporarily might expand the over-all memory * Footprint, it properly cleans up after itself. * ********/ Int F6 (char * Item1) { My_class C1; Int result; ... C1 = new my_class (Item1 ); ... Result = c1.x; Delete C1; Return result; } /******** *... * Note that F8 () is already ented to return a value * Which needs to be returned to heap; as F7 thinly * Wraps F8, any code which invokes F7 () must be * Careful to free () the return value. * ********/ Int * F7 () { Int * P; P = F8 (...); ... Return P; }

Make these format elements part of your daily work. You can use various methods to solve memory problems:

Dedicated Library

Language

Software Tools

In this field, I always think that the most useful and ROI is to consider improving the source code style. It does not require expensive or strict format; you can always cancel comments of segments unrelated to memory, but the definition that affects memory needs to be explicitly annotated. Adding a few simple words can make the Memory Results clearer and improve the memory programming.

I did not conduct a controlled experiment to verify the effect of this style. If your experience is the same as mine, you will find that the policies that do not describe the impact of resources are simply intolerable. This is simple, but it brings too many benefits.

Detection

 

Detection is a supplement to the encoding standard. The two have their own advantages, but the combined use of the two is particularly effective. Clever C or C ++ professionals can even browse unfamiliar source code and detect memory problems at a very low cost. With a small amount of practice and appropriate text search, you can quickly verify the balanced source subjects of * alloc () and free () or new and delete. Manual viewing of such content usually causes the same problems as in listing 7.

Listing 7. Tricky Memory leakage

The following is a reference clip: static char * important_pointer = NULL; void F9 () {< br> If (! Important_pointer) important_pointer = malloc (important_size); ... If (condition) /* Ooops! We just lost the reference important_pointer already held. */ important_pointer = malloc (different_size); ... }

If the condition is true, the automatic runtime tool cannot detect memory leaks. After careful source analysis, we can infer the correct conclusions from such conditions. I will repeat what I wrote about style: although many of the released memory issue descriptions all emphasize tools and languages, for me, the biggest result is the "soft" developer-centric process change. Any improvements you make in style and detection can help you understand the diagnostics produced by automated tools.

Static automatic syntax analysis

Of course, not only humans can read the source code. You should also make static syntax analysis part of the development process. Static syntax analysis is the content of lint, strictly compiled, and executed by several commercial products: scanning the source and target items accepted by the compiler, but this may be a symptom of errors.

You want to disable lint for your code. Although Lint is outdated and has some limitations, many programmers who have not used it (or its more advanced descendants) have made great mistakes. In general, you can write excellent professional quality code that ignores lint, but efforts to do so often result in major errors. Some of these errors affect the correctness of the memory. Even the most expensive license fee for products of this category is meaningless compared to the cost of first discovering memory errors. Clear source code. Now, even if the lint flag encoding may provide you with the required functions, there may be a simpler method. This method can meet the requirements of lint, and is relatively strong and portable.

Memory Library

The last two categories of remediation methods are significantly different from those of the first three. The former is lightweight; one can easily understand and implement them. On the other hand, memory libraries and tools usually have high licensing fees. For some developers, they need to be further improved and adjusted. Programmers who effectively use libraries and tools are people who understand lightweight static methods. The available libraries and tools are impressive: their quality as a group is high. However, even the best programmers may be confused by very capricious programmers who ignore the basic principles of memory management. I have observed that common programmers can only feel discouraged when trying to use the memory library and tools for isolation.

For these reasons, we urge C and C ++ programmers to first understand their own sources to solve memory problems. After this is done, the database is considered.

You can use several libraries to write common C or C ++ code and ensure improved memory management. Jonathan Bartlett introduced the main candidates in the 2004 comment column on developerworks, which can be obtained in the references section below. Libraries can solve a variety of memory problems, so it is very difficult to directly compare them; common topics in this regard include garbage collection, smart pointers, and smart containers. In general, the Library can automatically perform more memory management, so that programmers can make fewer mistakes.

I have various feelings about the internal database. They are working hard, but I see that they have achieved less success than expected in the project, especially in C. I have not carefully analyzed these disappointing results. For example, the performance should be as good as the corresponding manual memory management, but this is a gray area-especially when the garbage collection library processing speed is slow. The most clear conclusion from this practice is that C ++ seems to be able to better accept smart pointers than the code group concerned by C.

Memory tools

 

Development teams that develop really C-based applications need runtime memory tools as part of their development strategies. The introduced technologies are very valuable and indispensable. You may not know the quality and functions of the Memory tool before you try it yourself.

This article mainly discusses software-based memory tools. There is also a Hardware Memory debugger, which is considered in special cases (mainly when using dedicated hosts that do not support other tools.

Software Memory tools on the market include proprietary tools (such as IBM Rational purify and electric fence) and other open source code tools. Many of them can be used well with AIX and other operating systems.

All memory tools have the same functions: Build a specific version of the executable file (similar to the debug version generated by using the-G tag during compilation) exercise-related applications and research reports automatically generated by tools. Consider the program shown in listing 8.

Listing 8. Sample Errors

The following is a reference clip: Int main () { Char P [5]; Strcpy (P, "Hello, world ."); Puts (P ); }

This program can be "run" in many environments. It compiles, executes, and prints "Hello, world. \ n" to the screen. If you use a memory tool to run the same application, an array boundary violation report is generated in row 4. In terms of understanding software errors (copying fourteen characters to a space that can only contain five characters), this method is much less costly than searching for error symptoms at the customer. This is the credit of the Memory tool.

Conclusion

as a mature C or C ++ programmer, you realize that memory problems deserve special attention. By developing some plans and practices, you can find a way to control memory errors. Learn the correct mode of memory usage and quickly discover possible errors, making the technology described in this article part of your daily work. You can eliminate the symptoms in the application at the beginning, or it may take several days or weeks for debugging.