Najsłynniejsze błędy programistyczne [cz. 2]

Praca programisty może być skrajnie różna. Można programować aplikację i grę i w nieskończoność wypuszczać do nich łatki bez specjalnego strachu o efekty poprzednich bugów. Można też znaleźć się w przedziale odpowiedzialności na równi z neurochirurgiem. Wtedy już żadna łatka nie pomoże...

Praca programisty może być skrajnie różna. Można programować aplikację i grę i w nieskończoność wypuszczać do nich łatki bez specjalnego strachu o efekty poprzednich bugów. Można też znaleźć się w przedziale odpowiedzialności na równi z neurochirurgiem. Wtedy już żadna łatka nie pomoże...

Ariane 5, Lot 501

Tradycyjnie rozpoczniemy od lotów kosmicznych, bez ofiar śmiertelnych, ale za to z pokaźnymi ofiarami w funduszach. Ponownie poznacie winowajcę w formie wadliwego kodu i dowiecie się co nieco o sposobie programowania tego typu przedsięwzięć.

Ariane to znany i wieloletni program europejskiej agencji kosmicznej ESA. Opisywany lot 501 oderwał się od ziemi 4 czerwca 1996 r. Po kilku chwilach stał się lecącym w dół pomnikiem ignorancji i bezbrzeżnej głupoty inżynierów oraz programistów odpowiadających za poprawne przygotowanie oprogramowania. Nie, nie ma w tym ani odrobiny przesady.

Ariane 5 otrzymał platformę nawigacyjną od Ariane 4 na zasadzie kopiuj-wklej. Nikt nie przejął się tym, że przeciążenia oraz tor lotu różniły się znacznie od tych w Ariane 4. Było oczywiste, że oprogramowanie może nie poradzić sobie z tak odmiennymi warunkami wznoszenia. Fakt, że nie zdecydowano się na aktualizację, nie był jednak najgorszy. Otóż nie przeprowadzono ani jednej symulacji startu Ariane 5 ze starym oprogramowaniem. Poczyniono taki test zaraz po nieudanym starcie i efektem była oczywiście katastrofa.

Podczas pierwszych faz lotu (30 sekund po oderwaniu się od platformy Kourou ELA-3) autopilot zaczął gwałtownie korygować pozycje dyszy dopalaczy, by po chwili zrobić to samo z dyszą głównego silnika. Powodem takiej akcji były błędne dane dostarczone przez komputer nawigacyjny do modułu sterującego. Skąd wzięły się błędne dane?

Oprogramowanie pilota napisane zostało w języku Ada. Główną przyczyną katastrofy było przekroczenie zakresu liczb (integer overflow), co stało się przez wyłączenie asercji i nieprawidłową ochronę przed tego typu zdarzeniem (linijka poniżej ukazuje fragment kodu odpowiedzialny za "overflow").

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));

Błąd pojawił się, gdy przeprowadzona została niechroniona konwersja liczb z 32 bitów na 16 bitów. Poprawny zapis powinien wyglądać następująco:

L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));

if L_M_BH_32 > 32767 then

P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;

elsif L_M_BH_32 < -32768 then

P_M_DERIVE(T_ALG.E_BH) := 16#8000#;

else

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));

end if;

Dodatkowy kod to test na przekroczenie zakresu liczb. Jego brak spowodował gwałtowne zmiany kursu i pierwsze fazy dezintegracji przez przeciążenia. System kontroli lotu wysłał sygnał autodestrukcji i dokończył dzieła zniszczenia. Powyższy błąd programistyczny kosztował około 400 000 000 dol.

https://www.youtube.com/watch?v=qnHn8W1Em6E

Awaria prądu w USA i Kanadzie w 2003 r.

Dla ponad 50 milionów ludzi były to trzy dni strachu, paniki i prawdziwej lekcji przeżycia. Wszystko przez pewien serwer w niewielkiej sterowni korporacji FirstEnergy. Przez drobny błąd w oprogramowaniu niewielka i niegroźna awaria przekształciła się w niekontrolowaną katastrofę energetyczną. Awarii uległo aż 265 elektrowni! Cały Nowy Jork pogrążył się w ciemnościach. W ciągu kilku chwil miliony ludzi straciło dostęp do energii elektrycznej.

Za awarią stał wspominany w poprzednim odcinku cyklu "błąd hazardu". Tkwił on w oprogramowaniu zarządzania energią General Electric zainstalowanym w systemie XA/21 (odmiana Unix). Po pojawieniu się hazardu zawiesił się system alarmowy i tkwił w stanie bezczynności przez ponad godzinę. Przez ten czas operatorzy nie wiedzieli, co się dzieje, i nie mogli zareagować.

Co gorsza, po przepełnieniu się kolejki zadań padł główny serwer i zaraz po nim serwer awaryjny. Operatorzy w dalszym ciągu nie mogli zareagować, bo błąd spowodował zwiększenie opóźnienia wyświetlania obrazów na ekranach kontrolnych z 2 sekund do 59! Po kilku alarmujących telefonach i pierwszych awariach technicy, patrząc na monitory, uspokajali dzwoniących i informowali, że wszystko wygląda OK.

Pojawiające się w tym czasie nadwyżki energii nie mogły zostać wyrównane i spowodowały efekt domina. Przegrzane linie wysokiego napięcia zaczęły się rozciągać i opadać w kierunku drzew, gdzie następnie przepalały się i powodowały spięcia. Brak linii przesyłowej oznaczał konieczność konserwacji produkowanego prądu, co może trwać jedynie krótką chwilę. Elektrownie wyłączają się w trybie awaryjnym, jedna po drugiej. Brak poprawnej obsługi sieci powoduje złe przekierowania napięć. Kolejne linie wysokiego napięcia się przegrzewają i koło się zamyka.

Co ciekawe, poza zarzutem o używanie wadliwego oprogramowania pojawiły się także inne zastrzeżenia. Jednym z nich było nieprzycięcie drzew, co spowodowało większość przepaleń linii. Lawina pozwów wytoczonych przez fabryki, szpitale i osoby poszkodowane przez "blackout" sprawiła, że wiele spraw o odszkodowania toczy się do dzisiaj.