memleak(8)

🎀 memleak(8) 🎀

System Manager's Manual, page memleak(8) ✨

💖 NAME 💖

okay so memleak is the tool that prints a summary of outstanding allocations and their call stacks so you can catch memory leaks 🔍 it's Linux eBPF/bcc powered, obviously 💅

🦋 SYNOPSIS 🦋

memleak [-h] [-p PID] [-t] [-a] [-o OLDER] [-c COMMAND] [--combined-only] [--wa-missing-free] [-s SAMPLE_RATE] [-T TOP] [-z MIN_SIZE] [-Z MAX_SIZE] [-O OBJ] [INTERVAL] [COUNT]

🌸 DESCRIPTION 🌸

bestie, memleak literally traces and matches memory allocation and deallocation requests 🧚 and collects call stacks for every allocation. then it can show you which call stacks made allocations that never got freed. the main character of leaks 😭

When tracing a specific process, memleak instruments a list of libc allocation functions, specifically: malloc, calloc, realloc, posix_memalign, valloc, memalign, pvalloc, aligned_alloc, and free. When tracing all processes, memleak instruments kmalloc/kfree, kmem_cache_alloc/kmem_cache_free, and also page allocations made by get_free_pages/free_pages. 🫶

⚠️ memleak may introduce significant overhead when tracing processes that allocate and free many blocks very quickly. it's giving slowdown energy 💀 see the OVERHEAD section below, no cap.

This tool only works on Linux 4.6+ 🐧 Stack traces are obtained using the new BPF_STACK_TRACE APIs. For kernels older than 4.6, check the version under tools/old. Kernel memory allocations are intercepted through tracepoints, which are available on Linux 4.7+ ✨

🧚 REQUIREMENTS 🧚

you'll need CONFIG_BPF and bcc 🔧 non-negotiable, periodt.

👑 OPTIONS 👑

• -h — print the usage message 📖
• -p PID — trace this process ID only (filtered in-kernel) 🎯 this traces the libc allocator
• -t — print a trace of all allocation and free requests and their results 📜
• -a — print a list of allocations that weren't freed (plus their sizes) alongside their call stacks 🍓
• -o OLDER — only show allocations older than OLDER milliseconds. super useful for clearing out false positives 🙈 the default is 500 milliseconds
• -c COMMAND — run the specified command and trace only its allocations 🏃‍♀️ this traces the libc allocator too
• --combined-only — use statistics precalculated in kernel space. way less data gets pulled from the kernel ⚡ the tradeoff is you lose the time-based false positive filtering (-o) 😭
• --wa-missing-free — make up the action of free to ease misjudgments when free is missing 🩹
• -s SAMPLE_RATE — record roughly every SAMPLE_RATE-th allocation to cut down on overhead 🦋
• -t TOP — print only the top TOP stacks, sorted by size 🏆 the default is 10
• -z MIN_SIZE — capture only allocations larger than or equal to MIN_SIZE bytes 📏
• -Z MAX_SIZE — capture only allocations smaller than or equal to MAX_SIZE bytes 📐
• -O OBJ — attach to allocation functions in the specified object instead of resolving libc 🔮 ignored when kernel allocations are being profiled
• INTERVAL — print a summary of outstanding allocations and their call stacks every INTERVAL seconds ⏰ the default interval is 5 seconds
• COUNT — print the outstanding allocations summary COUNT times, then exit 👋

🎀 EXAMPLES 🎀

ok so here are the vibes, bestie 💅

Print outstanding kernel allocation stacks every 3 seconds:

# memleak 3

Print user outstanding allocation stacks and allocation details for the process 1005:

# memleak -p 1005 -a

Sample roughly every 5th allocation (~20%) of the call stacks and print the top 5 stacks 10 times before quitting:

# memleak -s 5 --top=5 10

Run ./allocs and print outstanding allocation stacks for that process:

# memleak -c ./allocs

Capture only allocations between 16 and 32 bytes in size:

# memleak -z 16 -Z 32

🌈 OVERHEAD 🌈

memleak can have significant overhead if the target process or kernel performs allocations at a very high rate 😭 pathological cases may exhibit up to 100x degradation in running time. most of the time though, memleak shouldn't cause a big slowdown, lowkey relief 💖 you can use the -s switch to reduce the overhead further by capturing only every N-th allocation. the -z and -Z switches can also cut overhead by only capturing allocations of specific sizes 🎯

option --combined-only saves processing time by reusing allocation statistics the kernel already calculated. it's faster, but it lacks info about particular allocations 🏎️

also, option --wa-missing-free makes memleak more accurate in complicated environments 🧠

to figure out how often your app is calling malloc/free, or how often your kernel is calling kmalloc/kfree, place a probe with perf and collect statistics. for example, to see how many calls to __kmalloc happen in a typical 10 second period:

# perf probe '__kmalloc'

# perf stat -a -e 'probe:__kmalloc' -- sleep 10

🦢 SOURCE 🦢

this is from bcc 🫶

https://github.com/iovisor/bcc

also look in the bcc distribution for a companion _examples.txt file with example usage, output, and commentary for this tool 📚

🖥️ OS 🖥️

Linux 🐧

🙈 STABILITY 🙈

⚠️ Unstable — still in development, so expect some chaos 🌪️

💜 AUTHOR 💜

Sasha Goldshtein 👩‍💻✨

---

bestie, that's the whole page 🎀 it's from the USER COMMANDS section, dated 2016-01-14, so it's a little vintage but still iconic 💅🌸 stay curious, find your leaks, and don't let those allocations sneak off unfreed 😘🦋