Zazwyczaj przyczyną błędnego działania programu jest bug w kodzie. Czy
znacie natomiast jakieś ciekawe sytuacje, w których program był
bezbłędny, a jego niewłaściwe działanie było spowodowane usterką
samego sprzętu, na którym działał, tzn. przypadki programowego
wykrycia błędu sprzętowego?
Ja z głośniejszych znam tylko ten: http://en.wikipedia.org/wiki/Pentium_FDIV_bug

do góry

W dniu 2013-06-01 18:43, Piotrek pisze:
> Zazwyczaj przyczyną błędnego działania programu jest bug w kodzie. Czy
> znacie natomiast jakieś ciekawe sytuacje, w których program był
> bezbłędny, a jego niewłaściwe działanie było spowodowane usterką
> samego sprzętu, na którym działał, tzn. przypadki programowego
> wykrycia błędu sprzętowego?
> Ja z głośniejszych znam tylko ten: http://en.wikipedia.org/wiki/Pentium_FDIV_bug

Już na wiki w tej kategorii masz wymienione kolejne:
http://en.wikipedia.org/wiki/Pentium_F00F_bug
http://en.wikipedia.org/wiki/Cyrix_coma_bug


Hmm, chyba wszystkie*) sprzętowe bugi, które przeszły
etap projektowania, zostały wykryte przez jakiś program.
Choćby przez program testujący;-)


*) a ten?
http://en.wikipedia.org/wiki/Green_Lightning_%28comp
uting%29
;-)

pzdr
bartekltg

do góry

Dnia Sat, 01 Jun 2013 09:43:38 -0700 po głębokim namyśle Piotrek rzekł:

> Zazwyczaj przyczyną błędnego działania programu jest bug w kodzie. Czy
> znacie natomiast jakieś ciekawe sytuacje, w których program był
> bezbłędny, a jego niewłaściwe działanie było spowodowane usterką samego
> sprzętu, na którym działał, tzn. przypadki programowego wykrycia błędu
> sprzętowego?
> Ja z głośniejszych znam tylko ten:
> http://en.wikipedia.org/wiki/Pentium_FDIV_bug

Oprócz błędów znanych są też przypadkowe:
http://www.cs.toronto.edu/~bianca/papers/sigmetrics0
9.pdf

Tego typu testy, autorstwa Google ale był podobny z LHC, którego
teraz nie mogę znaleźć, pokazują że niestety istnieje całkiem
realne ryzyko, że pojedyncze bity się trwale przestawią. Problem
dotyczy nawet pamięci z ECC, gdzie jeden przestawiony bit jest
"naprawiany" przez ECC, podobnie na dyskach istnieje ECC.

Mówiąc wprost, oprogramowanie często nie uwzględnia błędów
pamięci. W życiu straciłem tylko ze 3-4 systemy plików, z czego
2 przez błędy RAM - nie te przypadkowe, zdarzyły się systematyczne
pady RAM wykrywalne przez memcheck. Skutek jest taki, że oprogramowanie
niczego nie "zauważa" tylko robi manianę bo RAM zwraca złe dane,
a na błędy RAM większość oprogramowania nie jest odporna.
Podkreślam, że akurat te to wykrywalne systematyczne błędy, tych
przypadkowych w żaden sposób nie da się odtworzyć, a skutek może
być podobny chociaż w mniejszej skali.

Czyli, programiści: jeżeli zdarzy się segfault zawsze można zwalić
na promieniowanie jonizujące, które przestawiło bit w RAM i z
pewnym prawdopodobieństwem ta wymówka może być prawdziwa. Małym
prawdopodobieństwem, które w przypadku działających latami
serwerów staje się prawdopodobieństwem już dość realnym,
gdy pamięć nie ma ECC. Potem loterią są skutki, zależnie
od tego "w co trafi" może się zdarzyć albo nic, albo
regularna anomalia w strukturach danych, i albo ta zmiana
będzie chwilowa aż do padu systemu, albo zostanie utrwalona
w danych zabezpieczonych na X innych sposobów.

--
Edek

do góry

On Saturday, June 1, 2013 6:43:38 PM UTC+2, Piotrek wrote:
> Ja z głośniejszych znam tylko ten: http://en.wikipedia.org/wiki/Pentium_FDIV_bug

Jako ciekawostkę można podać, że AMD ma formalnie zweryfikowaną
jednostkę zmiennoprzecinkową. Podejrzewam, że Intel również.

w.

do góry