Studium przypadku: crash po długim czasie pracy prześledzony aż do wycieku uchwytów

Przegląd przypadku

Ten przypadek dotyczy aplikacji dla systemu Windows, która ulegała nagłej awarii dopiero po około miesiącu ciągłej pracy. Zaczęliśmy od uporządkowania punktów obserwacji, a ostatecznie zawęziliśmy poszukiwania do diagnozy skoncentrowanej na wycieku uchwytów. Kluczowe było to, że ustaliliśmy nie tylko samą przyczynę, lecz także to, które obserwacje należy przygotować w pierwszej kolejności.

Objawy

• Awaria nie pojawiała się w ciągu kilku dni, tylko wyłącznie po długotrwałej pracy
• Sposób, w jaki pojawiały się wyjątki, nie pozwalał łatwo ocenić, czy chodzi o wyciek
• Problem występował tylko w środowisku produkcyjnym, więc na maszynie deweloperskiej trzeba było zawęzić warunki odtworzenia błędu

Ograniczenia

• Czekanie miesiąc na każde odtworzenie błędu nie było realistyczne
• Ponieważ w grę wchodziły ponowne połączenia z kamerą i ścieżki błędów, same logi ścieżek poprawnego działania nie wystarczały
• Trzeba było móc w sposób ciągły obserwować, który zasób rośnie

Co obserwowaliśmy

• Cykliczny pomiar (heartbeat) Handle Count, Private Bytes i Thread Count
• Logi graniczne początku sesji, ponownego połączenia i zakończenia sesji
• Sparowane logi cyklu życia zasobów: create/open/register oraz close/dispose/unregister

Jak zawęziliśmy przyczynę

Nie próbowaliśmy badać „awarii po długotrwałej pracy” jako takiej. Najpierw zawęziliśmy warunki odtworzenia błędu do ścieżek błędów wokół ponownych połączeń i przekroczeń czasu (timeout). Dzięki temu mogliśmy uznać, że trafniejszą hipotezą jest wyciek uchwytów, a nie wyciek pamięci, i skupić na nim obserwację.

Jak poprawiliśmy sytuację

• Dodaliśmy monitorowane wskaźniki, aby można było śledzić trend wzrostu, a nie tylko moment awarii
• Uporządkowaliśmy logi graniczne, aby łatwiej było prześledzić, który komponent otworzył zasób, a który go zamknął
• Uporządkowaliśmy wyniki diagnozy tak, aby łatwo było powiązać je z późniejszą infrastrukturą testów ścieżek błędów

Usługi powiązane z tym przypadkiem

Ten przypadek łączy się zarówno z usługą Diagnostyka błędów i analiza przyczyn źródłowych, która pozwala wyizolować awarie występujące dopiero po długotrwałej pracy, jak i z usługą Tworzenie aplikacji dla systemu Windows, w ramach której od strony implementacji porządkujemy logowanie, ponowne łączenie i obserwację w trakcie eksploatacji.

Powiązane artykuły

Zapraszamy do konsultacji

Jeśli mają Państwo problem zbliżony do treści tej strony, prosimy o konsultację z nami, przekazując obecny kontekst oraz rodzaj potrzebnego wsparcia.