Analysis of Memory Leaks and Performance Issues in C/C++ Programs

Program memory issues can be divided into two main categories: memory leaks, where memory usage continuously grows without release, and performance problems caused by excessive memory fragmentation, which increase allocation cost, I/O consumption, and may even lead to crashes.

3.1 Memory Leak Case Analysis

Memory leaks in C/C++ programs arise mainly from unreasonable program design and excessive memory fragmentation. Design flaws include lost pointers, unreleased or partially released memory, infinite allocations, and data structures that never free memory.

3.1.1 Unreasonable Program Design

Typical design issues are:

Lost pointers to allocated memory.

Allocated memory not released or only partially released.

Infinite allocation without corresponding deallocation.

Data structures that never free their internal memory.

3.1.1.1 Pointer Loss

When a pointer to allocated memory is lost, the memory becomes unreachable and leaks. This often occurs in complex frameworks where developers are unaware of automatic memset operations that zero out pointers, as illustrated in the diagram (Figure 3‑1).

3.1.1.2 Improper Memory Release

Failure to release memory in exception paths or missing virtual destructors in C++ leads to leaks. Examples include code snippet 3‑1 where a branch does not free allocated memory, and cases where non‑virtual base destructors prevent derived class cleanup.

When using a custom memory pool, allocating memory outside the pool (as in code snippet 3‑2) can cause leaks because the pool’s clear function does not know about those allocations.

3.1.1.3 Infinite Allocation

Infinite allocation often occurs in loops that keep requesting memory without releasing it. In code snippet 3‑3, a vector exceeding 255 elements can cause an endless loop, leading to continuous memory consumption.

3.1.1.4 Containers Not Releasing Memory

Standard containers like std::vector grow exponentially and do not shrink automatically. Excessive growth can cause out‑of‑memory situations. Protobuf’s internal use of std::string and RepeatedField exhibits similar behavior, requiring periodic cleanup or swap‑based memory release.

3.1.2 Excessive Memory Fragmentation

Fragmentation is hard to diagnose and requires understanding of OS and allocator internals (e.g., tcmalloc). The tcmalloc diagram (Figure 3‑2) shows free‑list and large‑list handling, where large spans are rarely recycled, leading to persistent memory usage.

3.2 Program Performance Issues

Memory‑related performance degradation stems from fragmentation and frequent allocation/deallocation, causing page faults and CPU overhead. The article reviews glibc’s allocation mechanisms (brk/sbrk vs. mmap) and their impact on CPU usage.

Frequent allocations generate minor (minflt) and major (majflt) page faults; excessive major faults indicate heavy I/O and CPU slowdown. A case study shows that allocating 2 MiB per thread at 2000 requests/second can cause 20 000 page faults per second, dramatically increasing kernel CPU consumption.

Mitigation includes disabling mmap for large allocations (code snippet 3‑4) or adopting memory pools such as tcmalloc or jemalloc.

When the number of memory mappings exceeds the system limit ( /proc/sys/vm/max_map_count ), allocation failures occur, as illustrated by a real‑world example where a 74 GiB process on a 96 GiB server still ran out of memory due to excessive mmap‑based sub‑heaps.

Overall, using efficient allocators, proper deallocation patterns, and monitoring tools are essential for preventing memory leaks and performance degradation in C/C++ applications.