Hogyan hibakeresné egy olyan alkalmazást, amely nem nullával zárul?

Meg fogom vizsgálni az alkalmazás és a rendszer naplóit hibák vagy kivételek után, amelyek esetleg az esetlen leálláshoz vezettek. A strukturált naplók (JSON, kulcs-érték) használata megkönnyíti az elemzést.

Az eszközök nyomon követéséhez (például strace Linuxon) fogom használni, hogy nyomon kövessem azokat a rendszerhívásokat, amelyeket az alkalmazás végzett a leállás előtt. Ez segít azonosítani, mely erőforrások vagy műveletek okozták a problémát.

Ha lehetséges, az alkalmazást hibakeresőben (GDB, PDB stb.) fogom futtatni, hogy lépésenként végrehajtsam a kódot és elemezzem a változók állapotát a hiba pillanatában.

A core dumpokat meg fogom vizsgálni, ha generálták őket, például gdb segítségével, hogy a veremnyomot és a memória tartalmát megkapjam a hiba pillanatában.

Ellenőrizni fogom a környezet állapotát, amelyben az alkalmazás futott: memória elérhetőség, lemezterület, hálózati erőforrások, konfigurációs fájlok és környezeti változók.

Össze fogom hasonlítani az alkalmazás által használt összes függőség és könyvtár verzióját a stabilan működő verzióval.

Megpróbálom reprodukálni a problémát egy kontrollált tesztkörnyezetben, elkülönítve a potenciális külső tényezőket.

Figyelemmel fogom kísérni a metrikákat (CPU, memória, I/O), hogy azonosítsam a csúcsokat vagy anomáliákat a hiba előtt.

A strace használatának példája:

# Az összes rendszerhívás nyomon követése a PID 12345 folyamatnál
strace -p 12345

# A futó parancs rendszerhívásainak nyomon követése, kimenet mentése fájlba
strace -o syscalls.log ./my_app arg1 arg2

A core dump elemzése GDB-vel:

# GDB indítása a futtatható fájllal és a core dump-tal
gdb ./my_app core.12345

# GDB-ben:
# Verem nyomának megjelenítése
(gdb) bt

# A helyi változók értékeinek megjelenítése
(gdb) info locals

# A függvény argumentumainak értékeinek megjelenítése
(gdb) info args