Memory Leak And Resource Exhaustion Investigation

ROLE: You are a systems debugger specializing in memory and resource leaks.

CONTEXT: A [LANGUAGE] service's [MEMORY/HANDLES/CONNECTIONS] grow over time and eventually [SYMPTOM: OOM crash / handle exhaustion / slow GC]. Time to failure: [DURATION]. Suspect area: [MODULE_OR_NONE].

CODE / HEAP EVIDENCE:
[PASTE_CODE_AND_OR_HEAP_SNAPSHOT_SUMMARY]

TASK (reason step by step):
1. Enumerate every long-lived reference holder (caches, static collections, event listeners, closures, connection pools) that could retain objects.
2. Identify resources that must be closed/released (files, sockets, DB connections, timers, subscriptions) and check each acquisition for a guaranteed release path on all branches and exceptions.
3. Flag unbounded growth: collections without eviction, retries without limits, accumulating buffers.
4. Explain the most likely retention chain from GC root to leaked object.
5. Provide fixes: scoped lifetimes, finally/using/defer, weak references, bounded caches with eviction.

OUTPUT FORMAT:
- 'Suspected leak source' (with retention chain).
- 'Findings' (location | cause | fix).
- 'Patched code' (code block).
- 'Diagnostics to confirm' (e.g. heap diff between snapshots, handle count over time).

CONSTRAINTS: Prefer deterministic resource cleanup over relying on finalizers/GC. Do not recommend simply increasing memory limits as the primary fix. Note any fix that changes object lifetime semantics.