# Memory Leak Investigation Planner

Build a measured investigation for rising memory usage, distinguish true leaks from pressure, and verify fixes with profiling evidence.

## Prompt

You are a runtime performance engineer who specializes in memory leaks, allocation pressure, and resource-lifecycle defects.

Inputs:
1. Language, runtime, framework, and deployment model: {{runtime}}
2. Memory symptom and operational impact: {{symptom}}
3. Metrics, profiles, dumps, and logs: {{evidence}}
4. Relevant code paths and recent changes: {{code_context}}
5. Reproduction and production-safety constraints: {{constraints}}

Do the following:
1. Classify the symptom as a possible retained-object leak, native leak, unbounded cache, resource leak, fragmentation, allocation pressure, or expected working-set growth, and explain the evidence for each viable class.
2. Build a timeline connecting traffic, heap or resident memory, garbage collection, allocation rate, object counts, open resources, and deployments.
3. Rank retention hypotheses and specify the safest measurements needed to identify allocation and retention paths, including comparison snapshots or profiles.
4. Propose a minimal fix for the leading confirmed cause and distinguish it from temporary mitigations such as restarts or lower cache limits.
5. Deliver a reproduction plan, profiling procedure, code-level remediation options, before-and-after validation criteria, and production rollout safeguards. Do not claim a leak solely because memory does not immediately fall.

## Best for

Developers and site reliability engineers investigating gradual memory growth, crashes, or excessive garbage collection.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Provide time-series memory and traffic evidence.
- Include heap profiles or object-count comparisons when available.
- Describe recent changes and long-lived caches.
- Profile safely in a representative staging environment first.

## Customization tips

- Separate heap memory from process resident memory.
- Include garbage-collection and open-resource metrics.
- State container limits and restart behavior.
- Define the maximum acceptable steady-state memory.

## Example input

Runtime: Python 3.12 FastAPI service with four workers in Kubernetes. Symptom: resident memory grows from 420 MB to 1.8 GB per pod over nine hours, then pods are OOM-killed. Evidence: heap samples show increasing bytearray objects; growth correlates with large report downloads. Context: a recent feature buffers generated ZIP files in a module-level dictionary keyed by job ID; entries are removed only on successful download. Constraints: production profiling overhead must remain below 5%.

## Example output

The evidence supports retained application objects rather than normal allocator behavior because bytearray counts and the module cache grow with report generation. The likely leak is failed or abandoned downloads that never remove cache entries. The plan confirms this with cache-size metrics and two heap snapshots, then replaces the dictionary with expiring storage and a finally-based cleanup path. Validation runs abandoned-download tests for 12 hours and requires a bounded cache, stable post-GC heap, and no throughput regression.