Four Diagrams to Quickly Diagnose Linux Memory Leaks
This guide explains Linux's virtual‑physical memory model, shows how to inspect system and process memory via /proc files, demonstrates a 100 MiB allocation test, and provides a step‑by‑step workflow—including ps sorting and Valgrind usage—to locate and fix memory leaks.
Linux memory management separates virtual memory (address space) from physical memory (RAM). When a program requests memory, the kernel first reserves virtual pages and only maps them to physical pages when the memory is actually accessed, protecting the system from exhausting RAM.
1. Inspecting System Physical Memory
The /proc/meminfo file reports detailed physical memory statistics. Key fields include:
MemTotal : total RAM size.
MemFree : currently unused RAM.
MemAvailable : estimate of RAM available for new allocations (includes caches).
Buffers : memory used for filesystem buffers.
Cached : memory used for page cache.
2. Inspecting Process Virtual Memory
Each process exposes its memory usage through /proc/<pid>/status and /proc/<pid>/smaps. Important fields in status are:
VmPeak : peak virtual memory size.
VmSize : current virtual memory size.
VmHWM : peak resident set size (physical memory pressure).
VmRSS : current resident set size.
RssAnon , RssFile , RssShmem : breakdown of physical memory usage.
The smaps file provides per‑region details such as Size, Rss, Pss, and permission flags (e.g., rw-p for read‑write private mappings).
3. Practical Allocation Test
The following C program allocates 100 MiB but does not touch it:
#define SIZE (100 * 1024 * 1024)
int main(int argc, char *argv[]){
void *p = malloc(SIZE); // allocate 100 MiB
while(1) sleep(1);
return 0;
}Running the program and checking /proc/<pid>/status shows VmPeak and VmSize of about 100 MiB, while VmRSS remains only a few kilobytes because the memory has not been accessed.
After modifying the program to initialize the allocation with memset:
#define SIZE (100 * 1024 * 1024)
int main(int argc, char *argv[]){
void *p = malloc(SIZE);
memset(p, 0, SIZE); // force physical allocation
while(1) sleep(1);
return 0;
}The same status output now reports VmRSS ≈ 100 MiB, confirming that the virtual pages have been mapped to physical RAM. Corresponding smaps entries show Rss and Pss of 102404 kB for the heap region.
4. Detecting a Real Memory Leak
When a program forgets to free memory allocated with malloc, calloc or realloc, the leaked region remains in the heap or an anonymous mmap area. The diagnostic workflow is:
Confirm the leak : monitor /proc/meminfo over time; a decreasing MemFree indicates a leak.
Identify the leaking process : sort processes by resident size.
ps -eo pid,comm,rsz,vsz --sort=-rsz | head -n 10The rsz column shows physical memory usage; the top entry is the likely culprit.
Analyze the process memory : read /proc/<pid>/status and /proc/<pid>/smaps to locate large Rss / Pss regions, especially in the [heap] or anonymous mappings.
Pinpoint the leak source : combine code review with a dynamic analysis tool such as valgrind.
5. Using Valgrind
Install Valgrind (Ubuntu example): sudo apt-get install valgrind Run the program under Valgrind with comprehensive options:
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind.txt ./myprogramThe log contains a leak summary, e.g.:
==2657638== LEAK SUMMARY:
==2657638== definitely lost: 0 bytes in 0 blocks
==2657638== indirectly lost: 0 bytes in 0 blocks
==2657638== possibly lost: 104,857,600 bytes in 1 blocks
==2657638== still reachable: 0 bytes in 0 blocksInterpretation:
definitely lost : memory that cannot be accessed and must be freed.
indirectly lost : memory lost because a parent block is definitely lost.
possibly lost : memory reachable only via a pointer not at the block start (often a pointer arithmetic bug).
still reachable : memory still pointed to at program exit (e.g., global caches); usually safe but can be cleaned.
Conclusion
The article covered Linux's memory management fundamentals, demonstrated how to read system and process memory statistics, showed a hands‑on test to differentiate virtual from physical allocation, and presented a systematic leak‑detection workflow that culminates in Valgrind analysis. Following these steps equips developers with practical tools to locate and fix memory leaks on Linux.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
