APromptAura
0

Explain a suspected memory leak from heap snapshots and propose a fix

auto-checked, 4 days old
AauraNovice

The prompt

0 copies
I suspect a memory leak in service_name (language/runtime). I'll describe symptoms and, if available, heap snapshot diffs or growth-over-time data. Help me: 1. Distinguish a true leak (unbounded growth, objects that should be freed but aren't) from expected memory behavior (cache warming, GC not having run yet, connection pool at steady-state size). Ask what would confirm this if the data I gave isn't enough. 2. From the object types/counts that are growing, infer the likely retention path (what's holding a reference and preventing collection): common culprits are event listeners never removed, closures capturing large scope, unbounded caches/maps, or a connection pool not releasing. 3. Propose the smallest code change to fix the retention, and explain specifically why it breaks the reference chain. 4. Suggest one verification step (a metric to watch, a snapshot to retake) that would confirm the fix worked in production, not just in a local repro. 5. If the leak is architectural (e.g. a fundamentally unbounded cache with no eviction), say so plainly rather than proposing a band-aid. Symptoms/data: symptoms Relevant code: code

Run it in your model, then come back and report whether it worked, including the model and version.

Where it has been run

People and our automated sweep are counted separately. Only the People column is someone vouching for this prompt.

ModelVersionPeopleBrokeAutoLast
ClaudeHaiku 4.5001/14 days ago

Example output

The growth pattern (steady climb over 6 hours, no plateau, tied to request count not time) points to a true leak rather than cache warming, which would plateau. The dominant growing type is `Closure` retaining `RequestContext` objects, consistent with an event listener leak. Likely retention path: `eventBus.on('response', () => logMetrics(req))` inside the request handler registers a new listener on every request but never calls `.off()`, so each `RequestContext` stays alive for the lifetime of the singleton `eventBus`. Fix: move the listener registration outside the per-request handler, or explicitly call `eventBus.off('response', handler)` in a `finally` block. This breaks the reference chain because the closure over `req` is what's keeping the whole context object, including its buffers, alive. Verify: watch heap size after deploy for the same 6-hour window; it should plateau instead of climbing. If it's still climbing, retake a snapshot and check whether a different listener (there were two registered nearby) is the actual culprit.

0 comments

Sign in to comment or report what this prompt did for you.

Sign in

No comments yet. Run the prompt and report what you got.