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