Kuidas te debuggite rakendust, mis lõpetab mittetühja koodiga?

Ma teostan ülevaatuse rakenduse ja süsteemi logidest vigade või erandite osas, mis võisid põhjustada kriitilise sulgemise. Struktureeritud logimise (JSON, võti-väärtus) kasutamine hõlbustab analüüsi.

Ma kasutan jälgimisvahendeid (näiteks strace Linuxis), et jälgida süsteemikutsed, mida rakendus enne sulgemist tegi. See aitab näha, millised ressursid või operatsioonid põhjustasid probleemi.

Kui võimalik, käivitan rakenduse debuggeris (GDB, PDB jne), et samm-sammult koodi täita ja analüüsida rikke hetke muutujate olekut.

Uurin core dump'e, kui need on genereeritud, kasutades selliseid tööriistu nagu gdb, et saada virna jälg ja mälu sisu rikke hetkel.

Kontrollin keskkonda, kus rakendus käivitati: mälu saadavust, kettaruumi, võrguresursse, konfiguratsioonifaile ja keskkonnamuutujaid.

Võrdlen kõiki sõltuvusi ja teeke, mida rakendus kasutab, versiooniga, milles rakendus töötab stabiilselt.

Püüan reprodutseerida probleemi kontrollitavas testkeskkonnas, isolatsioonis potentsiaalsed välised tegurid.

Kasutades jälgimismeetreid (CPU, mälu, I/O), tuvastada tipukoormusi või anomaaliaid, mis eelnesid rikkele.

Näide strace kasutamisest:

# Jälgida kõiki protsessi süsteemikutsed PID-ga 12345
strace -p 12345

# Jälgida käivitatava käsu süsteemikutsed, salvestada väljund faili
strace -o syscalls.log ./my_app arg1 arg2

Näide core dump'i analüüsist GDB-ga:

# Käivitada GDB koos täidetava failiga ja core dump'iga
gdb ./my_app core.12345

# GDB sees:
# Näidata virna jälge
(gdb) bt

# Näidata kohalike muutujate väärtused
(gdb) info locals

# Näidata funktsioonide argumentide väärtused
(gdb) info args