Pointers and memory leaks in the C language

Source: Internet
Author: User
Tags ibm developerworks

(From: IBM developerWorks) Introduction

For anyone using C language, if asked what the biggest annoyance of C language is, many of them might answer pointers and memory leaks . These are really things that consume most of the developer's debugging time. Pointers and memory leaks may seem daunting to some developers, but once you understand the basics of pointers and their associated memory operations, they are the most powerful tools you have in C.

This article will share with you the secrets that developers should know before starting to use pointers for programming. The contents of this article include:

    • Type of pointer action that causes memory corruption
    • Checkpoints that must be considered when using dynamic memory allocation
    • Scenarios that cause memory leaks

If you know in advance what can go wrong, you can be careful to avoid traps and eliminate most of the pointers and memory related issues.

Where could something go wrong?

Several problem scenarios may occur, which can cause problems after the build is complete. As you work with pointers, you can use the information in this article to avoid many problems.

Uninitialized Memory

In this example, p 10 bytes have been allocated. These 10 bytes may contain garbage data, as shown in 1.

1

char*p = malloc( 10 );

Figure 1. Junk data

If p a snippet tries to access it before it is assigned to it, it may get garbage values, and your program may have unpredictable behavior. pmay have a value that your program has never expected.

Good practice is always used in combination memset with malloc , or used calloc .

1

2

char *p = malloc (10);

memset(p,’’,10);

Now, even if the same piece of code tries to p access it before it is assigned, the snippet also handles the Null value correctly (ideally, the value it should have) and then has the correct behavior.

Memory Overwrite

Since p 10 bytes have been allocated, if a code fragment tries to p write a 11-byte value, the action will automatically "eat" a byte from a different location without telling you. Let's assume q that the pointer represents that memory.

Figure 2. Original Q content

Figure 3. Post-Coverage Q content

As a result, the pointer q will have something that was never expected. Even if your module is well-coded, it may behave incorrectly due to certain memory operations performed by a co-existing module. The following sample code snippet can also illustrate this scenario.

1

2

3

char*name = (char*) malloc(11);

// Assign some value to name

memcpy( p,name,11); // Problem begins here

In this case, the memcpy operation attempted to write 11 bytes p , and the latter was only assigned 10 bytes.

As a good practice, whenever you write a value to a pointer, make sure that you cross-check the number of bytes available and the number of bytes written. In general, the memcpy function will be the checkpoint for this purpose.

Memory read out of bounds

Memory read out-of-bounds (overread) refers to the number of bytes read more than the number of bytes they should have. The problem is not too serious and is not detailed here. The following code provides an example.

1

2

3

char*ptr = (char*)malloc(10);

charname[20] ;

memcpy( name,ptr,20); // Problem begins here

In this example, the memcpy operation attempts to ptr read from 20 bytes, but the latter is only assigned 10 bytes. This can also lead to unwanted output.

Memory Leaks

Memory leaks can be really annoying. The following list describes some scenarios that cause a memory leak.

    • Re-assignment I'll use an example to illustrate the problem of re-assignment.

1

2

char*memoryArea = malloc(10);

char*newArea = malloc(10);

This assigns a value to the memory location shown in Figure 4 below.

Figure 4. Memory location

memoryAreaand newArea respectively are assigned 10 bytes, which are shown in their respective content 4. If someone executes a statement such as the following (pointer re-assigned value) ...

1

memoryArea = newArea;

It will certainly bring you trouble in the next stages of the module development.

In the preceding code statement, the developer assigns the memoryArea pointer to the pointer newArea . As a result, the memoryArea previously pointed memory location becomes orphaned, as shown in Figure 5 below. It cannot be freed because there is no reference to that location. This results in a 10-byte memory leak.

Figure 5. Memory leaks

    • Make sure that the memory location does not become orphaned before you assign a value to the pointer.
    • The first release of the parent block assumes that there is a pointer memoryArea to a 10-byte memory location. The third byte of the memory location points to a dynamically allocated 10-byte memory location, as shown in 6.
      Figure 6. Dynamically allocated memory

1

free(memoryArea)

If you release by calling Free memoryArea , the newArea pointer becomes invalid as a result. newAreathe memory location pointed to previously cannot be freed because there are no pointers to that location. In other words, the newArea location of the pointing memory becomes orphaned, resulting in a memory leak.

Whenever a structured element is released, and the element contains a pointer to a dynamically allocated memory location, the child memory location (in this case) should be traversed first, newArea and then freed from there and then traversed back to the parent node.

The correct implementation here should be:

1

2

free( memoryArea->newArea);

free(memoryArea);

Incorrect handling of return values

Sometimes, some functions return a reference to dynamically allocated memory. Tracking the memory location and handling it correctly becomes the calling function's responsibility.

1

2

3

4

5

6

7

8

9

char*func ( )

{

returnmalloc(20); // make sure to memset this location to ‘’…

}

voidcallingFunc ( )

{

func ( ); // Problem lies here

}

In the previous example, the callingFunc() call to the function in the function func() did not process the return address of the memory location. As a result, the func() 20-byte block allocated by the function is lost and causes a memory leak.

return what you have obtained.

There may be a lot of dynamic memory allocations when developing components. You may forget to track all pointers (pointing to these memory locations), and some memory segments are not released and remain assigned to the program.

Always keep track of all memory allocations and release them at any appropriate time. In fact, you can develop a mechanism to track these allocations, such as keeping a counter in the list node itself (but you must also consider the additional overhead of the mechanism).

Accessing a null pointer

Accessing a null pointer is dangerous because it can cause your program to crash. Always make sure that you are not accessing a null pointer.

Summarize

This article discusses several pitfalls that you can avoid when using dynamic memory allocation. To avoid memory-related problems, good practice is:

    • Always use together memset and malloc, or always use calloc .
    • Whenever you write a value to a pointer, be sure to cross-check the number of bytes available and the number of bytes written.
    • Make sure that no memory location becomes orphaned before you assign a value to the pointer.
    • Whenever you release a structured element that contains a pointer to a dynamically allocated memory location, you should first traverse the child memory location and start releasing it from there, and then traverse back to the parent node.
    • function return values that return dynamically allocated memory references are always handled correctly.
    • Each malloc must have a corresponding free.
    • Make sure that you are not accessing a null pointer.

Pointers and memory leaks in the

C language

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.