Kaip debuguosite programą, kuri baigiasi su nenulliniu grąžinimo kodu?

Aš patikrinsiu programėlės ir sistemos žurnalus dėl klaidų ar išimčių, kurios galėjo sukelti avarinį uždarymą. Struktūruoto žurnalavimo (JSON, raktas-reikšmė) naudojimas palengvina analizę.

Naudosiu sekimo įrankius (pvz., strace Linux'e) stebėti sisteminius iškvietimus, kuriuos vykdė programa prieš uždarymą. Tai padės pamatyti, kokie ištekliai ar operacijos sukėlė problemą.

Jei įmanoma, paleisiu programą derintuve (GDB, PDB ir kt.) žingsnis po žingsnio vykdyti kodą ir analizuoti būseną kintamųjų momento gedimo.

Tyrinėsiu core dump'us, jei jie buvo sugeneruoti, naudodamas tokias priemones kaip gdb, norėdamas gauti steko iškrovą ir atminties turinį gedimo metu.

Patikrinsiu aplinkos būseną, kurioje buvo paleista programa: atminties prieinamumą, disko vietą, tinklo išteklius, konfigūracijos failus ir aplinkos kintamuosius.

Palyginsiu visas priklausomybes ir bibliotekas, kurias naudoja programa, su versija, kurioje programa veikia stabiliai.

Bandysiu atkurti problemą kontroliuojamoje testavimo aplinkoje, izoliuodamas galimus išorinius veiksnius.

Naudosiu stebėjimo metrikas (CPU, atmintis, I/O), kad nustatyti viršpiko apkrovas ar anomalijas, įvykusias prieš gedimą.

Pavyzdys naudojimo strace:

# Stebėti visus proceso sisteminius iškvietimus su PID 12345
strace -p 12345

# Stebėti iškvietimus paleidžiant komandą, įrašyti išvestį į failą
strace -o syscalls.log ./my_app arg1 arg2

Pavyzdys analizės core dump'o su GDB:

# Paleisti GDB su vykdomuoju failu ir core dump'u
gdb ./my_app core.12345

# GDB viduje:
# Rodyti steko iškrovą
(gdb) bt

# Rodyti lokaliųjų kintamųjų reikšmes
(gdb) info locals

# Rodyti funkcijų argumentų reikšmes
(gdb) info args