Kā jūs debugosiet lietojumprogrammu, kas beidz ar nenulles izsaukuma kodu?

Es pārbaudīšu lietojumprogrammas un sistēmas žurnālus par kļūdām vai izņēmumiem, kas varētu novest pie avārijas. Strukturētas žurnālošanas (JSON, atslēga-vērtība) izmantošana atvieglo analīzi.

Es izmantosšu izsekošanas rīkus (piemēram, strace Linux) sistēmas izsaukumu izsekošanai, ko veica programma pirms aizvēršanās. Tas palīdzēs redzēt, kuri resursi vai operācijas izraisīja problēmu.

Ja iespējams, es palaidīšu programmu atkļūdotājā (GDB, PDB utt.) soli pa solim, lai izpildītu kodu un analizētu kļūdas brīža mainīgo stāvokli.

Es izpētīšu core dumpus, ja tie ir ģenerēti, izmantojot tādus rīkus kā gdb, lai iegūtu steka izsekošanu un atmiņas saturu kļūdas brīdī.

Es pārbaudīšu vidi, kurā tika palaista programma: pieejamību atmiņai, diska vietu, tīkla resursus, konfigurācijas failus un vides mainīgos.

Es salīdzināšu visas atkarības un bibliotēkas, ko izmanto programma, ar versiju, kurā programma darbojas stabili.

Es mēģināšu reproducēt problēmu kontrolētā testēšanas vidē, izolējot potenciālos ārējos faktorus.

Es izmantosšu uzraudzības metriku (CPU, atmiņa, I/O), lai identificētu virsotnes slodzes vai anomālijas, kas notika pirms kļūmes.

Piemērs strace izmantošanai:

# Izseko visus procesa sistēmas izsaukumus ar PID 12345
strace -p 12345

# Izseko izsaukumus, palaidot komandu, ierakstot izvadi failā
strace -o syscalls.log ./my_app arg1 arg2

Piemērs core dump analīzei ar GDB:

# Palaižot GDB ar izpildāmo failu un core dump
gdb ./my_app core.12345

# GDB iekšienē:
# Rādīt steka izkārtojumu
(gdb) bt

# Rādīt lokālo mainīgo vērtības
(gdb) info locals

# Rādīt funkciju argumentu vērtības
(gdb) info args