Memory leaks
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill memory-leaksAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Find the object that never gets freed by comparing heap snapshots and following retention paths. Use when a process grows in memory over time, gets OOM-killed, or slows under a garbage collector that keeps working harder.
SKILL.md
2.9 KB, as published. Nobody here has run it
Memory leaks
A leak is not memory that is high, it is memory that only goes up. Steady high usage is a capacity question. A slope that never returns to baseline after load stops is a reference someone forgot to drop, and guessing which one wastes hours. Measure the growth, then let the heap name the culprit.
Method
- Confirm it is a leak, not a plateau. Plot resident memory (RSS) over
a load cycle with
ps,/proc/<pid>/status, or your platform metrics. A leak keeps climbing after the workload ends and never recovers across several GC cycles. A cache filling to its cap and holding is not a leak. - Capture two heap snapshots under identical load. Take one after
warmup, run a fixed number of operations, take a second. In Node use
--inspectand Chrome DevTools orv8.writeHeapSnapshot(); in Python usetracemalloc.take_snapshot(); on the JVM usejmap -dump:live. Theliveor comparison mode matters: you want survivors, not garbage. - Diff the snapshots, sort by retained size delta. DevTools comparison
view,
tracemalloc.compare_to(old, 'lineno'), or Eclipse MAT on a JVM dump. The type whose instance count grows by roughly your operation count is the leak. Ten thousandListenerobjects after ten thousand requests is the answer pointing at itself. - Follow the retention path to a GC root. Right-click the leaked object and read "Path to GC Roots" (MAT) or the retainers tree (DevTools). The path ends at whatever holds the reference: a module-level list, an event emitter's handler array, a closure captured in a cache, a static map. That holder is the bug, not the leaked object.
- Cut the strongest reference, not every reference. Remove the listener
on teardown, bound the cache with an LRU or size cap, use
WeakMap/WeakReferencefor incidental associations, or clear the collection when the owning scope ends. Fix the one edge on the retention path. - Re-run the two-snapshot cycle to prove the slope is flat. Same load, same operation count. Retained delta near zero means fixed. A smaller but nonzero slope means a second leak: repeat from step 3.
Signals
- After N operations, does exactly one type grow by about N instances?
- Does RSS return to its warmup baseline after load stops and a forced GC?
- Does every leaked instance trace to the same holder on the retention path?
Boundaries
Native allocations (C extensions, off-heap buffers, memory-mapped files) do not show in a managed-heap snapshot; reach for Valgrind, ASan, or jemalloc profiling there. Fragmentation and allocator overhead can raise RSS without any leak, so trust the object-count trend over the raw RSS number.