APromptAura

#debugging

Top prompts tagged debugging.

0
p/codingAauraNovice4 days agohas example⁂auto-checked

Debug a suspected race condition in concurrent code

I suspect a race condition in this concurrent/multithreaded code. Symptoms: symptoms. Help me find it systematically: 1. Identify every piece of shared mutable state the concurrent units touch, and for each, whether access is currently synchronized (and how) or not. 2. For unsynchronized shared state, construct the specific interleaving of operations across threads/goroutines/tasks that would produce the symptom I described, step by step (Thread A does X, then Thread B does Y before A finishes, causing Z). 3. Rank candidate races by how well the interleaving you constructed matches the actual symptom, don't just list every unsynchronized variable as equally suspicious. 4. Propose the minimal synchronization fix (a lock, an atomic, a channel, immutability) for the top candidate, and explain why it's sufficient without over-synchronizing (adding a lock that serializes more than necessary). 5. Note if the fix could introduce a deadlock given other locks already held in this codebase, and how to check for that. Code: code Concurrency model: {{concurrency_model, e.g. Go goroutines / Java threads / Python asyncio}} Symptom details: symptoms
ClaudeGPT#debugging#concurrency#race-condition
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

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

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
ClaudeGPT#debugging#performance#memory-leak
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Debug a confusing stack trace by working backward from the error

I have a stack trace and error message that doesn't obviously point to the real bug. Help me find it methodically: 1. Start from the exception type and message: state precisely what condition triggers this exception in the language/library it comes from (don't guess generically, look at what that specific error actually means). 2. Walk the stack trace top to bottom, and for each frame, state what would have to be true at that point for the next frame's call to have happened. Stop at the first frame where something looks inconsistent with the code I've shown you. 3. Give your best hypothesis for the root cause, and separately, one alternative hypothesis in case the first is wrong, with a way to distinguish between them (a log statement, a debugger breakpoint, a value to print). 4. Do not propose a fix until the root cause is confirmed or I tell you to proceed with best guess. If I say proceed with best guess, clearly label the fix as unconfirmed. Stack trace: stack_trace Relevant code: code What I was doing when it happened: context
ClaudeGPT#debugging#stack-trace#javascript
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Root-cause a flaky test using a structured hypothesis funnel

This test fails intermittently, not on every run. Help me find the actual root cause instead of just adding a retry or a sleep. Work through this funnel and show your reasoning at each step: 1. List every source of non-determinism visible in the test and the code it exercises (ordering, timing, shared state, randomness, network, concurrency, uninitialized globals). 2. Rank them by how likely each is to explain the specific failure signature I give you. 3. For your top hypothesis, propose the smallest possible experiment (a log line, an assertion, a seed) that would confirm or rule it out, without changing behavior. 4. Only after that, propose a fix. Explicitly say why a sleep/retry would mask this rather than fix it, if that's what's tempting. 5. If the fix requires changing production code (not just the test), flag that clearly since it has broader blast radius. Test code: test_code Code under test: code_under_test Failure signature (error, stack trace, how often it fails): failure_signature
Claude#debugging#testing#flaky-tests
0