SkillVaultskills Browse all 500 skills

Debugging · Version 1.2.0 · Reviewed 2026-08-02

Memory Leak Investigator

Diagnose leak versus cache diagnosis and heap growth attribution with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Distinguishes genuine leaks from caching, fragmentation, and tuning artifacts, then localizes retention with heap evidence.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Leak versus cache diagnosis
  • Heap growth attribution
  • Retention path analysis

How Memory Leak Investigator works

You provide

Memory trend, heap snapshots, and restart correlation

It inspects

Live set after forced collection, not RSS alone

It decides

Leak, unbounded cache, or fragmentation — named

You verify

Two live-set measurements show a flat retention curve

What it checks first

Memory Leak Investigator distinguishes genuine leaks from caching, fragmentation, and tuning artifacts, then localizes retention with heap evidence. Use it when the work involves Leak versus cache diagnosis, Heap growth attribution, Retention path analysis.

  1. Live-set size after a forced full collection, which distinguishes a leak from retained-but-collectable memory.
  2. Whether growth correlates with request volume, unique inputs, or elapsed time — each implies a different retention source.
  3. Whether the process is genuinely leaking or the allocator is holding freed memory (RSS high, heap stable).
  4. Object counts by type across two heap snapshots, which localizes retention faster than total size.
  5. Whether restarts correlate with a deploy, which points at a code change rather than a gradual condition.

Failure modes it recognizes

  • An unbounded cache or memoization map that is working as designed but has no eviction policy.
  • Event listeners or subscriptions registered per request and never removed, retaining their entire closure scope.
  • A logging or metrics library buffering unbounded data when its sink is unavailable.
  • Heap fragmentation causing RSS growth while live heap remains stable, which no code change will fix.
  • A thread-local or async-context value retaining request state after completion.
  • A native or off-heap allocation invisible to the language-level heap profiler.

Answers it will reject

  • Increasing the memory limit, which changes the restart interval and nothing else.
  • Concluding "leak" from an RSS graph without comparing live sets after collection.
  • Chasing the largest object type when the growing count is what matters.
  • Adding a scheduled restart as the permanent fix, which hides the failure until it accelerates.

Decision rules it applies

  • Compare live sets at two points after forced collection; if the live set is flat, it is not a leak.
  • Diff object counts by type rather than total bytes to find the retention source.
  • If heap is stable while RSS grows, investigate the allocator and native allocations, not application code.
  • Every cache must declare a bound and an eviction policy; an unbounded cache is a leak with a nicer name.

Evidence it asks for

  • Capture two heap snapshots separated by a meaningful growth interval and diff them by object count.
  • Force a full garbage collection before each snapshot so collectable garbage does not distort the comparison.
  • Trace the retention path from a leaked instance back to a GC root rather than guessing the owner.

The method inside

  1. Establish what is actually true about leak versus cache diagnosis from the supplied evidence, and mark what is missing.
  2. Identify the mechanism behind heap growth attribution rather than restating the symptom.
  3. Choose the smallest defensible change for retention path analysis, weighing impact, confidence, effort, and reversibility.
  4. Update confidence only when evidence changes

Deliverables

  • Leak versus cache diagnosis assessment
  • Heap growth attribution decision and action plan
  • Retention path analysis verification checklist

Evidence requirements

  • Exact symptoms and timestamps
  • Reproduction conditions and recent changes
  • Logs, traces, metrics, code, or configuration

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Our service memory climbs steadily for days until it restarts. Is this a leak?

Expected output

Steady growth alone does not prove a leak; an unbounded cache and a heap that simply has not been pressured look identical on a memory graph. Force a full collection and compare live-set size across two points, because a real leak grows the live set while a cache grows only the retained set...

Boundaries and compatibility

Ideal for

  • Leak versus cache diagnosis: produce a decision or artifact grounded in supplied evidence.
  • Heap growth attribution: produce a decision or artifact grounded in supplied evidence.
  • Retention path analysis: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Guessing a root cause from a symptom alone
  • Claiming a fix worked without test evidence

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.