Jak budete laditovat aplikaci, která končí s nenulovým návratovým kódem?

Zkontroluji logy aplikace a systému na chyby nebo výjimky, které mohly vést k neočekávanému ukončení. Použití strukturovaných logů (JSON, klíč-hodnota) usnadňuje analýzu.

Použiji sledovací nástroje (například strace v Linuxu) k sledování systémových volání, která aplikace provedla před ukončením. To pomůže identifikovat, které zdroje nebo operace problém způsobily.

Pokud je to možné, spustím aplikaci v ladicím režimu (GDB, PDB atd.) pro krokování a analýzu stavu proměnných v okamžiku selhání.

Prozkoumám core dumpy, pokud byly generovány, pomocí nástrojů jako gdb, abych získal zásobník volání a obsah paměti v okamžiku selhání.

Zkontroluji stav prostředí, ve kterém byla aplikace spuštěna: dostupnost paměti, diskového prostoru, síťových zdrojů, konfiguračních souborů a proměnných prostředí.

Porovnám verze všech závislostí a knihoven používaných aplikací s verzí, na které aplikace stabilně funguje.

Pokud je to možné, pokusím se problém reprodukovat v kontrolovaném testovacím prostředí, izolováním potenciálních vnějších faktorů.

Použiji metriky monitorování (CPU, paměť, I/O), abych identifikoval špičkové zatížení nebo anomálie před selháním.

Příklad použití strace:

# Sledování všech systémových volání procesu s PID 12345
strace -p 12345

# Sledování systémových volání spuštěného příkazu, zaznamenání výstupu do souboru
strace -o syscalls.log ./my_app arg1 arg2

Příklad analýzy core dumpu s GDB:

# Spuštění GDB s spustitelným souborem a core dumpem
gdb ./my_app core.12345

# Uvnitř GDB:
# Zobrazit zásobník volání
(gdb) bt

# Zobrazit hodnoty lokálních proměnných
(gdb) info locals

# Zobrazit hodnoty argumentů funkcí
(gdb) info args