Kako ćete debugovati aplikaciju koja se završava sa nenul izlaznim kodom?

Проверитћу дневнике апликације и система на грешке или изузетке који су можда довели до неочекиваног затварања. Коришћење структурираних дневника (JSON, кључ-вредност) олакшава анализу.

Користићу алате за праћење (на пример, strace у Linux-у) да пратим системске позиве које је апликација извршила пре затварања. Ово ће помоћи у идентификовању ресурса или операција које су изазвале проблем.

Ако је могуће, покренућу апликацију у дебагеру (GDB, PDB итд.) ради по корак и анализе стања променљивих у тренутку квара.

Истражићу core dump-ове, ако су генерисани, користећи алате као што је gdb да добијем трагу стека и садржај меморије у тренутку квара.

Проверитћу стање окружења у којем је апликација радила: доступност меморије, простор на диску, мрежне ресурсе, конфигурационе датотеке и променљиве окружења.

Упоредићу верзије свих зависности и библиотека које користи апликација са верзијом на којој ради стабилно.

Покушаћу да репродукујем проблем у контролисаном тест окружењу, изолујући потенцијалне спољашње факторе.

Користићу метрике мониторинга (CPU, меморија, I/O) да идентификујем врхове оптерећења или аномалије пре квара.

Пример коришћења strace:

# Тражење свих системских позива процеса са PID 12345
strace -p 12345

# Тражење системских позива за покренуту команду, снимање излаза у фајл
strace -o syscalls.log ./my_app arg1 arg2

Пример анализе core dump-а са GDB:

# Покретање GDB са извршним фајлом и core dump-ом
gdb ./my_app core.12345

# Унутар GDB:
# Приказ трага стека
(gdb) bt

# Приказ вредности локалних променљивих
(gdb) info locals

# Приказ вредности аргумената функција
(gdb) info args