Why is repeated free () more harmful than memory leakage?

CIn program design, Memory Operation errors are the most common and hidden errors. Such errors often lead to Program breakdown, depletion of system resources, or serious security vulnerabilities.

In FreeBSD and most other BSD-derived systemsFree ()By default, the C function library calls abort () to terminate the program. In addition to the design of the malloc (3) function family, this is also a very important security feature. On the contrary, C function libraries of most systems, including * BSD, do not audit the heap. That is to say, from the perspective of API designers, memory leakage is not considered a very serious programming problem.

Why is there such a difference? In fact, memory leakage can also lead to serious problems, such as slow response speed, DoS caused by OS killing because the process occupies too many resources. To answer this question, let's take a look at the scenarios of the two problems.

Memory leakage refers to a scenario where a program allocates a piece of memory but no longer holds the pointer to reference this memory ). From the OS perspective, it knows the amount of memory held by the process; however, from the process perspective, it may not completely know what memory it holds.

In other words, memory leakage means that by traversing all the pointers in the process that can be stored in the stack or in the form of static variables and their successors, all allocated memory cannot be reached.

If the program does not have other problems, such as buffer overflow), when the program accesses the memory, it will not overwrite the data beyond the range at any time. That is, the data is overwritten to the memory unit that stores data in other parts of the program.

Repeated release refers to a scenario where, after a program allocates a piece of memory, it is used to release this piece of memory, but it does not erase or recycle all pointers pointing to this piece of memory, in other parts, the pointer pointing to the same memory unit is handed over to the memory distributor for release. In this case, we can assert that:

1. The program logic does not know that the memory has been released;

2. I believe that the write operation on this memory may have affected other part of the program, because this memory may have been allocated for other purposes.
Therefore, this should be seen as a fatal error that immediately stops running the program, because the program has encountered an exception, and the C function library does not have enough information to correct this exception. On the other hand, the program may have a heap buffer overflow.

In order to weaken the substantial security impact of such problems, modern memory splitters usually put memory blocks close to one another, and increase the data cache hit rate of the CPU, because the program usually tends to access similar memory structures at one time ).

This can reduce the damage caused by writing data to released memory blocks to some extent, because these memories are likely to be allocated to the same data structure, the harm of such write operations is often lower than writing data to other types of data structures, especially when the data contains some user input ).

Of course, to completely eliminate this type of problem, you need to add some new infrastructure for the programming language, such as strong type, managed memory, etc ). Modern programming languages such as Java, Python, And. net have adopted measures to avoid such problems. However, because of this, developers who are getting started with these languages and preparing to write C Programs need to pay more attention to these issues.