Raggi cosmici: qual è la probabilità che influenzino un programma?

546

Ancora una volta sono stato in una revisione del design e ho riscontrato l'affermazione secondo cui la probabilità di un particolare scenario era "inferiore al rischio di raggi cosmici" che colpisce il programma e mi è venuto in mente che non avevo la più pallida idea di cosa la probabilità è.

"Dal momento che ^2-128 è 1 su 340282366920938463463374607431768211456, penso che siamo giustificati nel prendere le nostre possibilità qui, anche se questi calcoli sono ridotti di un fattore di qualche miliardo ... Siamo molto più a rischio per i raggi cosmici per credetemi, credo. "

Questo programmatore è corretto? Qual è la probabilità che un raggio cosmico colpisca un computer e influisca sull'esecuzione del programma?

— Mark Harrison
fonte

42

"Lotterie vincenti: qual è la probabilità che influenzino un programma?"

— kennytm,

27

Dipende in parte da dove viene eseguito il programma e da quanto è schermato. Sulla Terra, il flusso di raggi cosmici è molto più basso rispetto allo spazio profondo, o persino vicino all'orbita terrestre. Il telescopio spaziale Hubble, ad esempio, produce immagini grezze che sono piene di tracce di raggi cosmici.

— Adam Hollidge,

89

Questo significa che d'ora in poi, quando qualcuno chiederà dei finallyblocchi, dovremo qualificarlo con "esegue sempre tranne se il programma esce, o se viene colpito da un raggio cosmico"?

— Skaffman,

72

Lavorando su un prototipo di rivelatore di particelle anni fa, l'ho programmato per stampare "ahi!" ogni volta che veniva colpito da un raggio cosmico. Bei tempi ...

— Beta

8

Delle domande più interessanti che ho letto qui da un po '. Una vera rivelazione. Conta su di me per riaprire.

— Agnel Kurian,

308

Da Wikipedia :

Gli studi condotti da IBM negli anni '90 suggeriscono che i computer presentano in genere un errore indotto da raggi cosmici per 256 megabyte di RAM al mese. ^[15]

Ciò significa una probabilità di 3,7 × ^10-9 per byte al mese o 1,4 × ^10-15 per byte al secondo. Se il programma viene eseguito per 1 minuto e occupa 20 MB di RAM, la probabilità di errore sarebbe

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

Il controllo degli errori può aiutare a ridurre le conseguenze del fallimento. Inoltre, a causa delle dimensioni più compatte dei chip, come commentato da Joe, il tasso di fallimento potrebbe essere diverso da quello che era 20 anni fa.

— kennytm
fonte

10

Ancora più importante, la dimensione della funzionalità del chip per le CPU nel 1995 era di circa 0,35 µm o 350nm. Ora è 1/10 di quella dimensione a 35nm.

— Joe Koberg,

18

È possibile che invece di ridurre il rischio, una riduzione delle dimensioni aumenti il rischio poiché ci vorrebbe meno energia per cambiare lo stato di ogni bit?

— Robert,

63

Le dimensioni ridotte aumentano sicuramente il rischio. I processori temprati per veicoli spaziali utilizzano dimensioni di funzioni molto grandi per evitare effetti di raggi cosmici.

— Joe Koberg,

22

Non solo i raggi cosmici, gli isotopi radioattivi nei materiali utilizzati nel chip rappresentano un problema molto più grande. I produttori fanno di tutto per assicurarsi che il silicio, la saldatura, l'incapsulamento ecc. Non contengano emettitori alfa o beta.

— Martin Beckett,

14

Wow! Ciò significa che circa 1 byte nel mio PC viene danneggiato ogni due giorni.

— Stefan Monov,

91

Apparentemente, non insignificante. Da questo articolo di New Scientist , una citazione da una domanda di brevetto Intel:

"Si sono verificati arresti anomali del computer indotti da raggi cosmici e si prevede che aumentino con frequenza man mano che i dispositivi (ad esempio i transistor) diminuiscono di dimensioni in chip. Si prevede che questo problema diventerà un importante limitatore dell'affidabilità del computer nel prossimo decennio."

Puoi leggere il brevetto completo qui .

— ire_and_curses
fonte

7

Perché aumentano con una diminuzione delle dimensioni del chip? Sicuramente un oggetto più piccolo ha meno probabilità di essere colpito da un raggio (cioè confrontare il lancio di una palla da tennis contro un muro, il lancio di un francobollo)

— Jonathan.

7

Perché quando le dimensioni dei componenti si riducono, diventano molto più sensibili ai colpi dei raggi cosmici.

— ire_and_curses

4

Sì, minore è minore probabilità di essere colpito, ma più probabilità che il colpo influenzerà lo stato.

— John Hascall,

2

@ire_and_curses [citazione necessaria]

— Anko

8

@Anko - È abbastanza ovvio. Man mano che un determinato componente diventa più piccolo, richiede meno tensione e meno carica per impostare un po '. Ciò lo rende più sensibile all'esplosione di energia dallo spazio. Tuttavia, ecco una citazione per te: man mano che i dispositivi di memoria LSI diventano più piccoli, diventano più sensibili ai guasti software indotti dalle radiazioni nucleari.

— ire_and_curses

55

Nota: questa risposta non riguarda la fisica, ma gli errori di memoria silenziosa con moduli di memoria non ECC. Alcuni errori possono provenire dallo spazio e altri - dallo spazio interno del desktop.

Esistono diversi studi sugli errori di memoria ECC su server farm di grandi dimensioni come cluster CERN e data center di Google. L'hardware di classe server con ECC è in grado di rilevare e correggere tutti gli errori a singolo bit e rilevare molti errori multi-bit.

Possiamo supporre che ci siano molti desktop non ECC (e smartphone mobili non ECC). Se controlliamo i documenti per i tassi di errore correggibili ECC (bitflip singoli), possiamo conoscere il tasso di corruzione della memoria silenziosa sulla memoria non ECC.

Studio su larga scala del CERN 2007 "Integrità dei dati" : i fornitori dichiarano " Tasso di errore bit di ^10-12 per i loro moduli di memoria ", " un tasso di errore osservato è di 4 ordini di grandezza inferiore al previsto ". Per le attività ad alta intensità di dati (8 GB / s di lettura della memoria) ciò significa che può capovolgere un singolo bit ogni minuto ( ^10-12 BER fornitori) o una volta ogni due giorni ( ^10-16 BER).
L'articolo di Google "Errori di DRAM allo stato brado: uno studio sul campo su larga scala" del 2009 afferma che possono esserci fino a 25000-75000 FIT a un bit per Mbit ( guasti nel tempo per miliardo di ore ), che equivale a 1 - 5 bit errori all'ora per 8 GB di RAM dopo i miei calcoli. Lo stesso documento afferma: " tassi di errore corretti medi di 2000–6000 per GB all'anno ".
Rapporto Sandia del 2012 "Rilevazione e correzione della corruzione silenziosa dei dati per il calcolo ad alte prestazioni su larga scala" : "il doppio bit era ritenuto improbabile" ma al denso Cray XT5 di ORNL sono "al ritmo di uno al giorno per oltre 75.000 DIMM" con ECC. E gli errori a bit singolo dovrebbero essere più alti.

Quindi, se il programma ha un set di dati di grandi dimensioni (diversi GB) o ha un'elevata velocità di lettura o scrittura della memoria (GB / se più) e funziona per diverse ore, possiamo aspettarci fino a diversi lanci di bit silenziosi sull'hardware del desktop. Questa velocità non è rilevabile dal memtest e i moduli DRAM sono buoni.

I cluster lunghi vengono eseguiti su migliaia di PC non ECC, come il grid computing su Internet di BOINC avrà sempre errori dovuti a salti di memoria e anche a errori silenziosi del disco e della rete.

E per macchine più grandi (10 mila server) anche con protezione ECC da errori a bit singolo, come vediamo nel rapporto di Sandia del 2012, ci possono essere capovolgimenti a doppio bit ogni giorno, quindi non avrai alcuna possibilità di eseguire parallelismi a grandezza naturale programma per diversi giorni (senza checkpoint regolari e riavvio dall'ultimo checkpoint valido in caso di doppio errore). Le enormi macchine avranno anche bit-flip nella loro cache e nei registri della cpu (trigger sia di architettura che di chip interni, ad esempio nel datapath ALU), perché non tutti sono protetti da ECC.

PS: Le cose andranno molto peggio se il modulo DRAM è difettoso. Ad esempio, ho installato la nuova DRAM nel laptop, che è morto diverse settimane dopo. Ha iniziato a dare molti errori di memoria. Cosa ottengo: il laptop si blocca, si riavvia Linux, esegue fsck, trova errori sul filesystem di root e dice che vuole fare il riavvio dopo aver corretto gli errori. Ma ad ogni riavvio successivo (ne ho eseguiti circa 5-6), nel filesystem di root sono ancora presenti errori.

— osgx
fonte

9

Materiale aggiuntivo da BH 2011: "Bitsquatting. Dirottamento DNS senza sfruttamento" media.blackhat.com/bh-us-11/Dinaburg/… elenca le moderne DRAM multi-GB con circa 10000-30000 FIT / Mbit (meno di 100 ore tra errori per ogni 128 MB). Il documento elenca anche articoli che concludono che la maggior parte degli errori lievi provengono da radiazioni, quasi tutti i casi - dai raggi cosmici e alcuni casi da emettitori alfa all'interno del PC. Gli autori di BH hanno fatto esperimenti e ottenuto 50000 accessi ai domini, cambiando 1 bit da siti popolari

— osgx

Complimenti per l'aggiunta di studi più recenti qui. Date le dinamiche del voto SO e il modo in cui sono accumulate nel tempo, è purtroppo difficile avere una presentazione aggiornata su questo argomento (qui).

— Fizz,

Abbiamo avuto un problema simile. Non abbiamo fatto nessuno studio esatto, ma abbiamo avuto alcuni dump di crash con lanci di bit visibili. Abbiamo controllato quei lanci di bit e si è scoperto che erano nella sezione del codice. Abbiamo confrontato con ciò che dovrebbe essere lì e non sembrava una modifica deliberata (cioè le istruzioni risultanti non avevano molto senso). Alla fine abbiamo avuto una semplice applicazione, che ha confrontato i dump di crash con le versioni (archiviate) rilasciate e filtrato tali casi. È interessante notare che la maggior parte di questi casi proveniva dall'Iran, dall'Arabia e penso che un altro paese dal Sud America (non ricordo ora).

— GiM,

2

Nel documento di Google sembra più che un po 'di RAM sia difettosa Circa un terzo delle macchine e oltre l'8% dei moduli DIMM nella nostra flotta hanno riscontrato almeno un errore correggibile all'anno. Le nostre percentuali di errori correggibili per DIMM si traducono in una media di 25.000-75.000 FIT (guasti nel tempo per miliardo di ore di funzionamento) per Mbit e un intervallo FIT mediano di 778 - 25.000 per Mbit (mediana per DIMM con errori), mentre studi precedenti riportano 200-5000 FIT per Mbit. Il numero di errori correggibili per DIMM è molto variabile, con alcuni DIMM che presentano un numero enorme di errori, rispetto ad altri.

— vartec,

31

Wikipedia cita uno studio di IBM negli anni '90 che suggerisce che "i computer presentano in genere un errore indotto da raggi cosmici per 256 megabyte di RAM al mese". Purtroppo la citazione era per un articolo su Scientific American, che non forniva ulteriori riferimenti. Personalmente, trovo che quel numero sia molto alto, ma forse la maggior parte degli errori di memoria indotti dai raggi cosmici non causa alcun problema reale o evidente.

D'altra parte, le persone che parlano di probabilità quando si tratta di scenari software in genere non hanno idea di cosa stiano parlando.

— JesperE
fonte

7

La probabilità che un bit venga capovolto deve essere moltiplicata per la probabilità che il bit abbia un notevole effetto sul programma. Immagino che la seconda probabilità sia molto più bassa di quanto pensi.

— Mark Ransom,

2

@Mark: i tipici programmi per computer non hanno quel tipo di tolleranza agli errori integrata. Un errore a bit singolo nel codice del programma molto probabilmente non arresta in modo anomalo il programma, se viene eseguito il codice non funzionante.

— Robert Harvey,

75

Sì, ma la maggior parte della memoria contiene dati, in cui la vibrazione non sarà quella visiblp.

— zoul

34

@zoul. lol su 'visiblp', ma se e = 1100101 e p = 1110000 allora sei la sfortunata vittima di lanci a 3 bit!

— PaulG

10

@Paul: o un battito di dito.

— mpen

30

Bene, apparentemente i raggi cosmici hanno causato il malfunzionamento dell'elettronica delle auto Toyota, quindi direi che la probabilità è molto alta :)

I raggi cosmici stanno davvero causando guai a Toyota?

— Kevin Crowell
fonte

23

"I regolatori federali stanno studiando se un'accelerazione improvvisa in Toyotas è collegata ai raggi cosmici". Questo è il motivo per cui non dovresti mai dare ai regolatori federali il potere sulla tua vita.

13

Immagino che la teoria qui sia che i raggi cosmici stiano lanciando bit nei cervelli più vecchi causandone il malfunzionamento e premendo il pedale sbagliato.

— Knox,

16

"Apparentemente"? Direi che è un'ipotesi selvaggia a questo punto. La mia ipotesi selvaggia è che questo fenomeno sia il risultato di quel vecchio incubo di sistemi embedded (in realtà i sistemi informatici più complessi) - la condizione della razza.

— Michael Burr,

7

@Knox: tira fuori il tuo vecchio cappello di stagnola, è utile!

3

Potrebbe non essere uno scherzo. Ho visto accadere cose davvero strane come questa prima. Non raro come la maggior parte della gente pensa.

— Brian Knoblauch,

25

Con ECC è possibile correggere gli errori a 1 bit dei raggi cosmici. Al fine di evitare il 10% dei casi in cui i raggi cosmici causano errori a 2 bit, le celle ECC sono in genere interlacciate su chip, quindi non ci sono due celle una accanto all'altra. Un evento di raggio cosmico che colpisce due cellule comporterà quindi due errori correggibili a 1 bit.

Stati del sole: (Codice 816-5053-10 aprile 2002)

In generale, gli errori soft dei raggi cosmici si verificano nella memoria DRAM con una frequenza compresa tra ~ 10 e 100 FIT / MB (1 FIT = 1 guasto del dispositivo in 1 miliardo di ore). Pertanto, un sistema con 10 GB di memoria dovrebbe mostrare un evento ECC ogni 1.000 a 10.000 ore e un sistema con 100 GB dovrebbe mostrare un evento ogni 100 a 1.000 ore. Tuttavia, questa è una stima approssimativa che cambierà in funzione degli effetti sopra descritti.

— giro
fonte

17

Gli errori di memoria sono reali e la memoria ECC aiuta. La memoria ECC correttamente implementata correggerà gli errori a singolo bit e rileverà gli errori a doppio bit (arrestando il sistema se viene rilevato un errore del genere). È possibile vedere da come le persone si lamentano regolarmente di ciò che sembra essere un problema software che viene risolto eseguendo Memtest86 e scoprire brutti ricordi. Ovviamente un fallimento transitorio causato da un raggio cosmico è diverso da un pezzo di memoria costantemente in errore, ma è rilevante per la domanda più ampia di quanto dovresti fidarti che la tua memoria funzioni correttamente.

Un'analisi basata su una dimensione residente di 20 MB potrebbe essere appropriata per applicazioni banali, ma i sistemi di grandi dimensioni dispongono abitualmente di più server con grandi memorie principali.

Link interessante: http://cr.yp.to/hardware/ecc.html

Purtroppo il link Corsair nella pagina sembra essere morto.

— JANM
fonte

I bitplips di raggi cosmici potrebbero non essere distribuiti uniformemente, in particolare se includiamo tempeste solari sotto l'ombrello "eventi di raggi cosmici". Se hai due o più bitflip all'interno dello stesso byte, l'ECC tipico non sarà in grado di correggere l'errore.

— Tobixen,

@tobixen Rilevare un errore a doppio bit è meglio che continuare a funzionare con dati errati. Il prossimo passo dopo ECC è Chipkill con mirroring DIMM ...

— Jan

13

Questo è un vero problema ed è per questo che la memoria ECC viene utilizzata nei server e nei sistemi integrati. E perché i sistemi di volo sono diversi da quelli terrestri.

Ad esempio, si noti che le parti Intel destinate ad applicazioni "integrate" tendono ad aggiungere ECC al foglio delle specifiche. A Bay Trail manca un tablet, poiché renderebbe la memoria un po 'più costosa e probabilmente più lenta. E se un tablet si blocca un programma ogni volta in una luna blu, all'utente non importa molto. Il software stesso è comunque molto meno affidabile dell'HW. Ma per gli SKU destinati all'uso in macchinari industriali e automobilistici, ECC è obbligatorio. Da qui, ci aspettiamo che il SW sia molto più affidabile e che gli errori causati da sconvolgimenti casuali sarebbero un vero problema.

I sistemi certificati secondo IEC 61508 e standard simili di solito hanno sia test di avvio che controllano che tutta la RAM sia funzionante (nessun bit bloccato a zero o uno), sia la gestione degli errori in fase di esecuzione che tenta di recuperare da errori rilevati da ECC, e spesso anche attività di scrubber di memoria che attraversano e leggono e scrivono continuamente memoria per assicurarsi che vengano notati eventuali errori che si verificano.

Ma per il software per PC tradizionale? Non un grande affare. Per un server di lunga durata? Utilizzare ECC e un gestore degli errori. Se un errore irreversibile uccide il kernel, così sia. Oppure si diventa paranoici e si utilizza un sistema ridondante con esecuzione di blocco in modo che se un core viene danneggiato, l'altro può subentrare mentre il primo core si riavvia.

— jakobengblom2
fonte

I bitplips di raggi cosmici potrebbero non essere distribuiti uniformemente, in particolare se includiamo tempeste solari sotto l'ombrello "eventi di raggi cosmici". Un'improvvisa esplosione può causare diverse cadute di bit all'interno di un byte e gli algoritmi ECC non saranno in grado di correggere un errore.

— Tobixen,

12

Se un programma è critico per la vita (ucciderà qualcuno se fallisce), deve essere scritto in modo tale da essere sicuro per il fallimento o ripristinarsi automaticamente da tale fallimento. Tutti gli altri programmi, YMMV.

Le toyotas ne sono un esempio. Dite quello che volete su un cavo dell'acceleratore, ma è non è un software.

Vedi anche http://en.wikipedia.org/wiki/Therac-25

— Robert Harvey
fonte

Non dimenticare il software per le valvole a farfalla. I sensori e il cablaggio per le valvole a farfalla sono il punto debole. Il mio sensore di posizione dell'acceleratore Mitsubishi non è riuscito in un generatore di numeri casuali ... Nessuna accelerazione involontaria, ma sicuramente non ha fatto nulla di buono per la miscela di carburante!

— Brian Knoblauch,

3

@Brian: un buon software avrebbe capito che i punti dati erano discontinui e ha concluso che i dati erano cattivi.

— Robert Harvey,

..e poi cosa ... Sono richiesti buoni dati. Sapere che è male non aiuta nessuno. Non qualcosa su cui puoi magicamente aggirare.

— Brian Knoblauch,

3

@Brian: Beh, per prima cosa, puoi intraprendere azioni correttive in base alla consapevolezza che i tuoi dati sono cattivi. Puoi smettere di accelerare, per esempio.

— Robert Harvey,

Sì, puoi (e dovresti) dati su cheksum. Il miglior end-to-end. Tuttavia, ciò riduce solo le possibilità di corruzione. Immagina che la tua istruzione "is this valid" ottenga il bit danneggiato nella memoria o nel registro CPU proprio quando vuoi diramare al gestore degli errori.

— Verifica il

11

Una volta ho programmato dispositivi che volavano nello spazio, e poi tu (presumibilmente, nessuno mi ha mai mostrato alcun documento a riguardo, ma si diceva che fosse una conoscenza comune nel settore) puoi aspettarti che i raggi cosmici inducano continuamente errori.

— erikkallen
fonte

8

Sopra l'atmosfera accadono due cose: 1) il flusso totale è più alto 2) molto di più si presenta sotto forma di particelle pesanti e molto energiche (con energia sufficiente per capovolgere un po 'in un piccolo spazio).

— dmckee --- ex gattino moderatore

Per quanto riguarda i riferimenti, ci sono libri (ad esempio, books.google.com/books?hl=en&lr=&id=Er5_rzW0q3MC ), conferenze (ad esempio, radecs2015.org , seemapld.org , e altri), e carte bizzeffe su questo argomento . I raggi cosmici non sono uno scherzo nel settore aerospaziale. Sono uno dei motivi principali per cui molti veicoli spaziali utilizzano computer con tempra rad, molti dei quali hanno la potenza di elaborazione di un moderno tostapane intelligente.

— David Hammen,

8

"eventi di raggi cosmici" sono considerati avere una distribuzione uniforme in molte delle risposte qui, questo potrebbe non essere sempre vero (cioè supernova). Sebbene "raggi cosmici" per definizione (almeno secondo Wikipedia) proviene da esterno spazio, ritengo sia giusto anche includere locali tempeste solari (alias espulsione di massa coronale sotto lo stesso ombrello. Ritengo che possa causare più bit per capovolgere entro un breve periodo di tempo, potenzialmente sufficiente per corrompere anche la memoria abilitata ECC.

È noto che le tempeste solari possono causare un po 'di caos con i sistemi elettrici (come l' interruzione di corrente del Quebec nel marzo 1989 ). È molto probabile che anche i sistemi informatici possano essere interessati.

Circa 10 anni fa ero seduto proprio accanto a un altro ragazzo, eravamo seduti con ciascuno dei nostri computer portatili, era in un periodo con un tempo solare piuttosto "burrascoso" (seduto nell'Artico, potevamo osservare questo indirettamente - un sacco di aurora boreale per essere visto). Improvvisamente - nello stesso istante - entrambi i nostri laptop si sono schiantati. Stava eseguendo OS X e io stavo eseguendo Linux. Nessuno di noi è abituato all'arresto anomalo dei laptop: è una cosa abbastanza rara su Linux e OS X. È possibile escludere più o meno bug di software comuni dal momento che eravamo in esecuzione su diversi sistemi operativi (e non è successo durante un salto secondo). Sono arrivato ad attribuire quell'evento alla "radiazione cosmica".

In seguito, la "radiazione cosmica" è diventata uno scherzo interno al mio posto di lavoro. Ogni volta che succede qualcosa con i nostri server e non riusciamo a trovare alcuna spiegazione, attribuiamo scherzosamente l'errore alla "radiazione cosmica". :-)

— tobixen
fonte

7

Più spesso, il rumore può danneggiare i dati. I checksum sono usati per combattere questo a molti livelli; in un cavo dati c'è in genere un bit di parità che viaggia lungo i dati. Ciò riduce notevolmente la probabilità di corruzione. Quindi, ai livelli di analisi, i dati senza senso vengono in genere ignorati, quindi anche se un po 'di corruzione superasse il bit di parità o altri checksum, nella maggior parte dei casi verrebbero ignorati.

Inoltre, alcuni componenti sono schermati elettricamente per bloccare il rumore (probabilmente non i raggi cosmici).

Ma alla fine, come hanno detto gli altri risponditori, c'è il bit o il byte occasionale che viene confuso, ed è lasciato al caso se si tratta di un byte significativo o meno. Nel migliore dei casi, un raggio cosmico confonde uno dei bit vuoti e non ha assolutamente alcun effetto, o si arresta in modo anomalo al computer (questa è una buona cosa, perché il computer è tenuto a non fare del male); ma nel peggiore dei casi, beh, sono sicuro che puoi immaginare.

— Ricket
fonte

I bitplips di raggi cosmici potrebbero non essere distribuiti uniformemente, in particolare se includiamo tempeste solari sotto l'ombrello "eventi di raggi cosmici". Se sono presenti due bitflip all'interno dello stesso byte, il controllo del bit di parità fallirà. Numerosi bitflip e algoritmi ECC probabilmente non saranno in grado di correggere un errore.

— Tobixen,

5

L'ho sperimentato: non è raro che i raggi cosmici si ribaltino un po ', ma è molto improbabile che una persona lo osservi.

Stavo lavorando a uno strumento di compressione per un programma di installazione nel 2004. I miei dati di test erano alcuni file di installazione Adobe di circa 500 MB o più decompressi.

Dopo una noiosa corsa di compressione e una corsa di decompressione per testare l'integrità, FC / B ha mostrato un byte diverso.

All'interno di quel byte l'MSB era capovolto. Ho anche lanciato, preoccupandomi di avere un insetto pazzo che sarebbe emerso solo in condizioni molto specifiche - non sapevo nemmeno da dove iniziare a cercare.

Ma qualcosa mi ha detto di ripetere il test. L'ho fatto funzionare ed è passato. Ho impostato uno script per eseguire il test 5 volte durante la notte. Al mattino erano passati tutti e 5.

Quindi è stata sicuramente una piccola svolta del raggio cosmico.

— rep_movsd
fonte

Decisamente? Non potrebbe essere stata una variabile non inizializzata che non ha mai ottenuto un valore iniziale negativo nei test successivi?

— Doug65536,

Compilo sempre con W3 o W4 su VS - Anche Rational Purify, non c'erano bug di quel tipo.

— rep_movsd,

Ah, scusa non sapevo che quelle opzioni del compilatore e Rational Purify fossero assolutamente infallibili. =)

— doug65536

Considerando che il codice è stato quindi messo in produzione e compresso e non compresso correttamente centinaia di GB, non vi era traccia di un bug simile.

— rep_movsd,

4

Potresti anche dare un'occhiata all'hardware Fault Tolerant.

Ad esempio Stratus Technology costruisce server Wintel chiamati ftServer che avevano 2 o 3 "schede madri" in fase di blocco, confrontando il risultato dei calcoli. (questo avviene anche nei veicoli spaziali a volte).

I server Stratus si sono evoluti da chipset personalizzati a lockstep sul backplane.

Un sistema molto simile (ma software) è il lockstep VMWare Fault Tolerance basato su Hypervisor.

— Eckes
fonte

4

Come punto dati, questo è appena successo sulla nostra build:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

Assomiglia molto fortemente ad un capovolgimento che si verifica durante una compilazione, in un posto molto significativo in un file sorgente per caso.

Non sto necessariamente dicendo che si trattasse di un "raggio cosmico", ma il sintomo corrisponde.

— dascandy
fonte