Czy kiedykolwiek zastanawialiście się, jakie dziwne, ciekawe i nieprawdopodobne błędy w oprogramowaniu spotkali programiści lub użytkownicy? Dzisiaj przedstawię wam kilka takich przypadków, które miały nieprzewidziane skutki lub same w sobie zdawały się być nieprawdopodobne. Są też historie o mniej zabawnych implikacjach.
Zaczniemy jednak od Windows, w którym znalazło się miejsce na dwie ciekawe historie, które... mogą wydawać się nieprawdopodobne, ale jednak się wydarzyły. A zatem - zaczynamy!
Zacznijmy od mniej znanego błędu, który powodował, że na pasku postępu w eksploratorze Windows pojawiały się krótsze czasy, gdy poruszało się myszką. Brzmi absurdalnie, prawda? Jak to możliwe, że ruch myszki wpływał na "prędkość kopiowania plików"? Otóż okazuje się, że ten błąd wynikał z tego, jak Windows generował liczby losowe. System operacyjny używał tzw. generatora liczb pseudolosowych, który potrzebował jakiegoś źródła entropii, czyli nieprzewidywalności. Jednym z takich źródeł były właśnie ruchy myszki. Im więcej entropii, tym lepsza jakość liczb losowych. A co to ma wspólnego z paskiem postępu? Ano to, że Windows używał liczb losowych do szacowania czasu kopiowania plików. Im lepsze liczby losowe, tym dokładniejsze szacunki. Dlatego też poruszanie myszką sprawiało, że pasek postępu "przyspieszał", bo system lepiej przewidywał czas potrzebny na zakończenie operacji.
Skrócenie prezentowanego czasu wykonania operacji to jedno, ale realne obniżenie go to drugie. I to też miało kiedyś miejsce. Tak, dobrze czytacie. W systemie Windows 95 istniała możliwość REALNEGO skrócenia czasu kopiowania plików z jednego miejsca na drugie poprzez poruszanie myszką w trakcie operacji. Nie jest to żart ani legenda miejska, ale potwierdzony fakt przez wielu użytkowników i nawet przez samych twórców systemu.
Jak to możliwe? Otóż wszystko sprowadza się do sposobu, w jaki Windows 95 obsługiwał przerwania sprzętowe. Na przykład, gdy naciskamy klawisz na klawiaturze, klawiatura wysyła przerwanie do procesora, aby ten odczytał kod klawisza i przekazał go do systemu operacyjnego. Każdy proces miał swój własny czas na wykonanie swoich zadań i musiał "dobrowolnie" oddać kontrolę nad procesorem innym procesom. Jeśli jednak proces tego nie robił, to mógł zablokować cały system i uniemożliwić działanie innych programów.
Windows 95 miał w tym zakresie pewne zabezpieczenie: gdy procesor otrzymywał przerwanie sprzętowe, to natychmiast przerywał bieżący proces i obsługiwał przerwanie. Po zakończeniu obsługi przerwania, procesor wracał do poprzedniego procesu i kontynuował jego wykonanie. Niektóre przerwania jednak nie poddawały się takiej kontroli. Oznaczało to, że procesor czekał na zakończenie bieżącego procesu przed obsługą przerwania. Jednym z takich przerwań było przerwanie od dysku twardego, które sygnalizowało zakończenie operacji odczytu lub zapisu danych.
I tu dochodzimy do sedna sprawy. Gdy kopiowaliśmy pliki z jednego miejsca na drugie, Windows 95 wykonywał operacje odczytu i zapisu danych na dysku twardym. Każda taka operacja generowała przerwanie od dysku twardego - procesor musiał czekać na zakończenie bieżącego procesu przed obsługą przerwania od dysku. Ale myszka również generowała przerwania sprzętowe, ale było ono obsługiwane w innym trybie. Oznaczało to, że procesor natychmiast przerywał bieżący proces i obsługiwał przerwanie od myszki. Po obsłużeniu przerwania od myszki, procesor wracał do poprzedniego procesu i kontynuował jego wykonanie.
Natomiast Windows obsługiwał je w kolejności od najwyższego do najniższego priorytetu. A przerwanie od myszki miało wyższy priorytet niż przerwanie od dysku twardego. Oznaczało to, że gdy procesor wracał do poprzedniego procesu po obsłużeniu przerwania od myszki, to natychmiast otrzymywał kolejne przerwanie od dysku twardego i obsługiwał je. W ten sposób, poruszanie myszką powodowało, że procesor szybciej obsługiwał przerwania od dysku twardego i tym samym przyspieszał operacje odczytu i zapisu danych. Efekt był taki, że im szybciej i częściej poruszaliśmy myszką, tym szybciej kopiowaliśmy pliki. Niektórzy użytkownicy twierdzili, że mogli skrócić czas kopiowania plików nawet o połowę dzięki temu trikowi. Mogło jednak się okazać, że taki "lifehack" mógł spowodować uszkodzenie kopiowanych plików.
Chociażby błąd roku 2000 (Y2K), który polegał na tym, że wiele systemów komputerowych używało dwóch cyfr do przechowywania roku (np. 99 zamiast 1999). Po przejściu na rok 2000 mogły wystąpić różne problemy z datami i godzinami. Na szczęście większość z nich została naprawiona przed końcem stulecia i... apokalipsa się nie wydarzyła. A wielu wieściło tego typu właśnie wydarzenia, mówiąc nawet o tym, że świat dosłownie się "zatrzyma". Byli także oszuści, którzy sprzedawali "specjalne oprogramowanie" chroniące ludzi przed skutkami błędy Y2K. Warto wspomnieć także o błędzie Pentium FDIV, który dotyczył błędnych obliczeń dzielenia na niektórych procesorach firmy Intel. W środowisku naukowym i inżynieryjnym spowodował on, że wiele z badań miało błędne obliczenia - a to wypaczało sens naprawdę ogromnej liczby prac. Intel nie dość, że musiał wymienić miliony uszkodzonych procesorów i zapłacić odszkodowania.
A teraz coś zdecydowanie mniej zabawnego. Chodzi o Therac-25, który był odpowiedzialny za śmierć sześciu pacjentów poddawanych radioterapii. Ten błąd polegał na tym, że maszyna do napromieniowywania dawki promieniowania dziesięciokrotnie większej niż powinna. Przyczyną tego była luka w oprogramowaniu sterującym maszyną.
Być może słyszeliście wcześniej o maszynie do radioterapii, która była produkowana przez Atomic Energy of Canada Limited (AECL) w latach 80. XX wieku. Miała ona zaawansowany system komputerowy, który kontrolował jej działanie. Niestety, okazało się, że system ten zawierał poważne błędy i niedopatrzenia, które doprowadziły do sześciu tragicznych wypadków między 1985 a 1987 rokiem. W tych wypadkach pacjenci byli narażeni na ogromne przedawkowanie promieniowania, które spowodowało ciężkie obrażenia, okaleczenia i śmierć.
Jak mogło do tego dojść? Otóż okazało się, że oprogramowanie Therac-25 było oparte na kodzie z poprzednich modeli maszyn (Therac-6 i Therac-20), które nie miały takich problemów. Jednak te modele miały dodatkowe zabezpieczenia sprzętowe, które zapobiegały nadmiernemu promieniowaniu. Therac-25 nie miał takich zabezpieczeń i polegał tylko na oprogramowaniu, które nie było wystarczająco przetestowane i sprawdzone pod kątem błędów. Doszło także do tego, że... naukowcy i inżynierowie ignorowali wszelkie ostrzeżenia i sygnały o nieprawidłowościach. Dopiero po interwencji FDA (amerykańskiej agencji ds. żywności i leków) i CRPB (kanadyjskiego biura ochrony przed promieniowaniem) firma AECL wprowadziła niezbędne poprawki i ulepszenia.
Tu doskonale widać, jak ważne jest odpowiedzialne projektowanie i testowanie oprogramowania, zwłaszcza w systemach krytycznych dla życia ludzi. Jedno zabezpieczenie to zdecydowanie za mało, aby działać w tak krytycznych zastosowaniach - tego boleśnie doświadczyli nie tylko twórcy maszyny, ale przede wszystkim ludzie, którzy padli ofiarami tego błędu. Wśród podobnie niebezpiecznych błędów (nikt nie zginął, ale taka pomyłka kosztowała 370 mln dolarów) można przywołać także ten w Ariane 5, który spowodował wybuch rakiety nośnej podczas jej pierwszego lotu. Wynikał on z tego, że oprogramowanie rakiety używało kodu z poprzedniej wersji Ariane 4, która miała inne parametry lotu. W wyniku tego doszło do przepełnienia bufora i awarii systemu sterowania.
Błędy w oprogramowaniu mogą mieć poważne konsekwencje, ale zdecydowanie nie można powiedzieć, że są one nieciekawe. Są nawet... fascynujące. Na podstawie tych przywołanych doskonale widać, że wyczerpujące czasami QA-owców testy oraz szybkie reagowanie na feedback od użytkowników są wręcz kluczowe. Historia pokazuje nam dobitnie, że istnieją zabawne błędy, ale są też takie, których udział w splocie innych nieprzewidzianych zdarzeń spowodował okaleczenie lub nawet śmierć ludzi.
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
