Sujet : debugging
-
Modes de défaillance de Jev 1.13 : lecture littérale, comptage, dates, indirection et dégradation du contexte
Les neuf modes de défaillance documentés par TypeSafe pour jev-1.13 (revus par le fournisseur le 2026-09-17), leurs implications pour un agent qui délègue des décisions au modèle et les contournements documentés : conditions exactes dans les instructions, arithmétique et traitement des dates dans le code, état filtré et absence de dépendance à des invariants structurels entre questions distinctes.
-
La méthode USE pour trouver les goulets d’étranglement
Pour chaque ressource (CPU, mémoire, disques, réseau, verrous), vérifier l’utilisation, la saturation et les erreurs ; la méthode USE est une liste de contrôle qui repère rapidement les goulets d’étranglement sans commencer par des suppositions sur la couche applicative.
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Mit git bisect den verursachenden Commit finden
git bisect sucht binär zwischen einem bekannten guten und einem schlechten Commit; mit einem Prüfskript findet es den ersten fehlerhaften Commit ohne manuelles Ausprobieren.
-
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.
-
Debugging HTTP with curl: verbose output, timing breakdown and forcing the connection
Use curl -v or --trace-ascii to see the exact request and response, --write-out with time_namelookup, time_connect, time_appconnect, time_starttransfer and time_total to locate where the time goes, and --resolve or --connect-to to send a request to one specific server while keeping the Host header and TLS name intact.
-
A systematic debugging method
Debugging as a loop of observation, hypothesis, prediction and experiment: reproduce first, narrow the search space by bisection, change one thing at a time, and record what was ruled out.
-
Linear history shortens regression diagnosis
Hypothesis: teams with a linear, squash- or rebase-based integration history locate regressing commits faster with bisect than teams with merge-heavy histories, because each step is a coherent, buildable change.
-
Characterisation tests: pinning what legacy code actually does
Before changing code whose intended behaviour is unknown, write tests with placeholder expectations, read the real output from the failure, record it as the expectation and name the test after what the code does; surprises are logged, not fixed, until the owners decide.
-
Aus einem Fehler einen Regressionstest machen
Vor der Korrektur wird der Fehler als automatischer Test nachgestellt, der aus dem gemeldeten Grund fehlschlägt; die Korrektur macht ihn grün, und der Test bleibt als Wächter. Mit pytest lässt sich der eine Test isoliert wiederholen (`--lf`), und ein aufgeschobener Fehler wird als `xfail(strict=True)` dokumentiert, damit ein stilles Verschwinden auffällt.
Lisible par machine : JSON