Jak będziesz debugować aplikację, która kończy się kodem wyjścia różnym od zera?

Sprawdzę logi aplikacji i systemu pod kątem błędów lub wyjątków, które mogły doprowadzić do awaryjnego zamknięcia. Użycie strukturalnych logów (JSON, klucz-wartość) ułatwia analizę.

Użyję narzędzi do śledzenia (np. strace w Linuxie), aby śledzić wywołania systemowe wykonywane przez aplikację przed jej zamknięciem. Pomoże to zidentyfikować, które zasoby lub operacje spowodowały problem.

Jeśli to możliwe, uruchomię aplikację w debugerze (GDB, PDB itp.), aby krok po kroku przeanalizować kod i stan zmiennych w momencie awarii.

Zbadałem zrzuty pamięci (core dumps), jeśli zostały wygenerowane, korzystając z narzędzi takich jak gdb, aby uzyskać ślad stosu i zawartość pamięci w momencie awarii.

Sprawdzę stan środowiska, w którym uruchamiano aplikację: dostępność pamięci, przestrzeń dyskowa, zasoby sieciowe, pliki konfiguracyjne i zmienne środowiskowe.

Porównam wersje wszystkich zależności i bibliotek używanych przez aplikację z wersją, na której działa ona stabilnie.

Spróbuję odtworzyć problem w kontrolowanym środowisku testowym, izolując potencjalne czynniki zewnętrzne.

Użyję metryk monitorowania (CPU, pamięć, I/O), aby wykryć szczyty obciążenia lub anomalie poprzedzające awarię.

Przykład użycia strace:

# Śledzenie wszystkich wywołań systemowych procesu o PID 12345
strace -p 12345

# Śledzenie wywołań systemowych dla uruchamianej komendy, zapis wyjścia do pliku
strace -o syscalls.log ./my_app arg1 arg2

Przykład analizy zrzutu pamięci (core dump) z GDB:

# Uruchom GDB z plikiem wykonywalnym i zrzutem pamięci
gdb ./my_app core.12345

# Wewnątrz GDB:
# Wyświetl ślad stosu
(gdb) bt

# Wyświetl wartości lokalnych zmiennych
(gdb) info locals

# Wyświetl wartości argumentów funkcji
(gdb) info args