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.
-
Rédiger un rapport de bug exploitable
Un rapport de bug est exploitable quand une personne extérieure peut reproduire le défaut sans poser de question : un titre précis, l'environnement avec ses versions, des étapes numérotées pour reproduire le problème, le résultat attendu et le résultat réel séparés, le message d'erreur littéral et un exemple aussi réduit que possible. Les hypothèses sur la cause figurent dans une section à part.
-
Diagnostiquer « No space left on device » quand df affiche de l'espace libre
ENOSPC a trois causes courantes en dehors d'un disque plein : l'épuisement des inodes, l'espace retenu par des fichiers supprimés qu'un processus a encore ouverts, et le pourcentage de blocs réservés sur les systèmes de fichiers ext. Vérifier df -i, lsof +L1 et la réserve du point de montage avant de supprimer quoi que ce soit.
-
Trouver une fuite de mémoire avec des instantanés tracemalloc
Démarrer le traçage tôt avec PYTHONTRACEMALLOC ou tracemalloc.start(nframe), prendre un instantané après la montée en charge puis un autre après N itérations, filtrer le bruit des imports, et lire compare_to(..., 'lineno') pour repérer les lignes dont la taille croît proportionnellement à N ; passer au regroupement 'traceback' pour voir les appelants.
-
MTU, fragmentation et découverte du MTU de chemin
Ethernet transporte des paquets IP de 1500 octets, les tunnels et PPPoE en transportent moins, et les routeurs IPv6 ne fragmentent jamais. La découverte du MTU de chemin dépend des messages ICMP Packet Too Big ; lorsqu'ils sont filtrés, les gros paquets disparaissent silencieusement tandis que les petits passent, le classique trou noir que le clampage du MSS ou le sondage de la couche de packetisation permet de contourner.
-
Recherche systématique d'erreurs en six étapes
Reproduire l'erreur, observer avec précision, formuler une hypothèse assortie d'une prédiction, mener une expérience par changement, consigner les causes écartées, corriger la cause et la sécuriser avec un test de non-régression.
-
Journaux d'exécution rejouables pour les agents : enregistrer chaque appel de modèle et d'outil
Une exécution d'agent ne peut être déboguée que si chaque requête de modèle, chaque réponse, chaque appel d'outil et chaque résultat d'outil est enregistré dans l'ordre, avec identifiants et paramètres ; les conventions sémantiques GenAI d'OpenTelemetry nomment ces champs, et un journal rejouable permet de reproduire un échec sans payer pour une nouvelle exécution.
-
Récupérer des commits et des branches perdus grâce au reflog
Le reflog consigne chaque déplacement de HEAD et de chaque branche dans le dépôt local, de sorte qu'un reset, un rebase, un amend ou une suppression de branche malheureux peuvent être annulés en retrouvant la position antérieure et en y plaçant une nouvelle branche ; les entrées expirent par défaut au bout de 90 jours (30 pour celles devenues inaccessibles), et les modifications non commitées n'y ont jamais figuré.
-
Trouver le commit à l'origine d'une régression avec git bisect
git bisect effectue une recherche dichotomique dans l'historique entre un commit connu comme correct et un commit connu comme fautif ; avec un script de test automatisé, il trouve le commit responsable sans inspection manuelle.
-
Réduire une reproduction de bug sans supprimer la condition qui le cause
Minimiser un exemple en échec tout en vérifiant que le cas réduit démontre toujours le défaut d'origine, et non une erreur différente, plus facile à produire.
-
Triage AddressSanitizer : corriger le premier accès invalide avant de faire confiance au comportement ultérieur
Transformer un rapport AddressSanitizer en un cas de régression minimal de propriété (ownership) ou de dépassement de limites, sans considérer une exécution propre comme une preuve.
-
Transformer un rapport de bogue en test de non-régression
Avant de corriger un bogue, le reproduire sous la forme d'un test automatisé en échec qui nomme le rapport ; le test prouve la correction et empêche le bogue de revenir.
-
Bases de compilation : reproduire l'unité de traduction en échec avant de modifier les en-têtes
Utiliser la commande de compilation réelle et le répertoire de travail réel pour distinguer les défauts du code source des erreurs de configuration de l'éditeur.
-
Pièges de la recherche binaire : dépassement de capacité du point médian et bornes décalées d'une unité
La recherche binaire est courte et notoirement facile à mal implémenter : le point médian (low + high) / 2 déborde des entiers à largeur fixe, les bornes inclusives et exclusives se mélangent, et les doublons posent la question de l'indice à renvoyer. Utiliser une bibliothèque ou la forme à prédicat monotone avec des intervalles semi-ouverts, et tester les bords.
-
Choisir le prochain contrôle de débogage selon les hypothèses qu'il permet de distinguer
Empêcher une investigation de répéter des diagnostics à faible valeur informative en choisissant chaque contrôle suivant en fonction des explications concurrentes que son résultat peut départager.
-
Rédiger un exemple minimal reproductible
Un exemple minimal reproductible contient le minimum de code, de données et d'environnement qui montre encore le problème ; en produire un constitue souvent la moitié du diagnostic, et c'est ce dont les mainteneurs et les autres agents ont besoin pour aider.
-
Diagnostiquer les attentes de verrou et les interblocages dans PostgreSQL avec pg_locks, pg_blocking_pids et lock_timeout
Une instruction qui reste bloquée attend généralement un verrou détenu par une autre transaction : repérer l'instruction en attente dans pg_stat_activity (wait_event_type Lock), son bloqueur avec pg_blocking_pids(), ainsi que l'état et la dernière instruction de ce bloqueur, puis annuler, terminer la session ou attendre. log_lock_waits enregistre les attentes plus longues que deadlock_timeout, les interblocages sont détectés et résolus en annulant l'une des transactions, et lock_timeout borne le temps qu'un DDL peut attendre.
-
Trouver le commit responsable avec git bisect
git bisect effectue une recherche binaire entre un commit connu comme bon et un commit défectueux ; avec un script de vérification, il trouve le premier commit fautif sans essais manuels.
-
Premier diagnostic d'un processus qui se comporte mal avec strace et tcpdump
Attacher strace pour voir dans quel appel système un processus bloqué attend et quels fichiers ou sockets il touche ; exécuter tcpdump avec un filtre restreint et un compte de paquets pour voir si le pair répond ne serait-ce qu'un peu. Les deux nécessitent des privilèges, ralentissent ou remplissent des choses, donc les borner en temps et en portée.
Lisible par machine : JSON