Topic: debugging
-
Jev 1.13 failure modes: literal reading, counting, dates, indirection and context rot
The nine failure modes TypeSafe documents for jev-1.13 (reviewed by the vendor on 2026-09-17), what each means for an agent that delegates decisions to the model, and the documented workaround for each: exact conditions in the instructions, arithmetic and date logic in code, filtered state, and no reliance on structural invariants between separate questions.
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
How to write a usable bug report
A bug report is usable when a stranger can reproduce the bug without asking follow-up questions: a precise title, the environment with versions, numbered steps to reproduce, expected and actual results kept separate, the verbatim error message, and an example that is as small as possible. Guesses about the cause go in a separate section.
-
Diagnosing 'No space left on device' when df shows free space
ENOSPC has three common causes besides a full disk: exhausted inodes, space held by deleted files that a process still has open, and the reserved-blocks percentage on ext filesystems. Check df -i, lsof +L1 and the mount's reservation before deleting anything.
-
Finding a memory leak with tracemalloc snapshots
Start tracing early with PYTHONTRACEMALLOC or tracemalloc.start(nframe), take a snapshot after warm-up and another after N iterations, filter import noise, and read compare_to(..., 'lineno') for lines whose size grows proportionally to N; switch to 'traceback' grouping to see the callers.
-
MTU, fragmentation and path MTU discovery
Ethernet carries 1500-byte IP packets, tunnels and PPPoE carry less, and IPv6 routers never fragment. Path MTU discovery depends on ICMP Packet Too Big messages; when those are filtered, large packets vanish silently while small ones pass, the classic black hole that MSS clamping or packetization-layer probing works around.
-
Systematic debugging in six steps
Reproduce the bug, observe it precisely, form a hypothesis with a prediction, run one experiment per change, record ruled-out causes, then fix the cause and lock it in with a regression test.
-
Replayable run logs for agents: recording every model and tool call
An agent run can only be debugged if every model request, response, tool call and tool result is recorded in order with identifiers and parameters; the OpenTelemetry GenAI semantic conventions name the fields, and a replayable log lets a failure be reproduced without paying for a new run.
-
Recovering lost commits and branches with the reflog
The reflog records every movement of HEAD and of each branch in the local repository, so a bad reset, rebase, amend or branch deletion can be undone by finding the earlier position and putting a new branch on it; entries expire after 90 days (30 for unreachable ones) by default, and uncommitted changes were never in it.
-
Finding the commit that introduced a regression with git bisect
git bisect performs a binary search over history between a known-good and a known-bad commit; with an automated test script it finds the offending commit without manual inspection.
-
Reducing a bug reproduction without removing the condition that causes it
Minimize a failing example while checking that the reduced case still demonstrates the original defect rather than a different, easier-to-produce error.
-
AddressSanitizer triage: fix the first invalid access before trusting later behavior
Turn an AddressSanitizer report into a minimal ownership or bounds regression case without treating a clean run as proof.
-
Turning a bug report into a regression test
Before fixing a bug, reproduce it as a failing automated test that names the report; the test proves the fix and prevents the bug from returning.
-
Compilation databases: reproduce the failing translation unit before changing headers
Use the real compile command and working directory to distinguish source defects from editor configuration errors.
-
Binary search pitfalls: midpoint overflow and off-by-one boundaries
Binary search is short and famously easy to get wrong: the midpoint (low + high) / 2 overflows fixed-width integers, inclusive and exclusive bounds get mixed, and duplicates raise the question of which index to return. Use a library or the monotone-predicate form with half-open intervals, and test the edges.
-
Choosing the next debugging check by the hypotheses it can distinguish
Stop an investigation from repeating low-information diagnostics by choosing each next check for the competing explanations its result can separate.
-
Writing a minimal reproducible example
A minimal reproducible example contains the least code, data and environment that still shows the problem; producing one is often half of the diagnosis and is what maintainers and other agents need to help.
-
Diagnosing lock waits and deadlocks in PostgreSQL with pg_locks, pg_blocking_pids and lock_timeout
A statement that hangs is usually waiting for a lock held by another transaction: find the waiter in pg_stat_activity (wait_event_type Lock), its blocker with pg_blocking_pids(), and the blocker's state and last statement, then cancel, terminate or wait. log_lock_waits records waits longer than deadlock_timeout, deadlocks are detected and resolved by aborting one transaction, and lock_timeout bounds how long DDL may wait.
-
Finding the offending commit with git bisect
git bisect performs a binary search between a known good and a known bad commit; with a test script it finds the first bad commit without manual trial and error.
-
First look at a misbehaving process with strace and tcpdump
Attach strace to see which system call a stuck process waits in and which files or sockets it touches; run tcpdump with a narrow filter and a packet count to see whether the peer answers at all. Both need privileges, both slow or fill things, so bound them in time and scope.
Machine-readable: JSON