Rayos cósmicos: ¿cuál es la probabilidad de que afecten a un programa?

546

Una vez más, estaba en una revisión de diseño, y encontré la afirmación de que la probabilidad de un escenario particular era "menor que el riesgo de que los rayos cósmicos" afectaran el programa, y ​​se me ocurrió que no tenía la menor idea de qué era eso. la probabilidad es

"Dado que 2 -128 es 1 de 340282366920938463463374607431768211456, creo que estamos justificados para arriesgarnos aquí, incluso si estos cálculos están desactivados por un factor de unos pocos miles de millones ... Estamos mucho más en riesgo de que los rayos cósmicos jodernos, creo ".

¿Es correcto este programador? ¿Cuál es la probabilidad de que un rayo cósmico golpee una computadora y afecte la ejecución del programa?

statistics physics probability error-detection risk-analysis Mark Harrison
fuente
42
"Ganar loterías: ¿Cuál es la probabilidad de que afecten a un programa?"
kennytm
27
Depende en parte de dónde se ejecute el programa y qué tan bien esté protegido. En la Tierra, el flujo de rayos cósmicos es mucho más bajo que en el espacio profundo, o incluso cerca de la órbita de la Tierra. El telescopio espacial Hubble, por ejemplo, produce imágenes en bruto que están plagadas de rastros de rayos cósmicos.
Adam Hollidge
89
¿Significa esto que a partir de ahora, cuando alguien pregunte sobre los finallybloques, tendremos que calificarlo con "siempre se ejecuta, excepto si el programa sale o si recibe un rayo cósmico"?
skaffman
72
Trabajando en un prototipo de detector de partículas hace años, lo programé para imprimir "¡ay!" cada vez que fue golpeado por un rayo cósmico. Buenos tiempos ...
Beta
8
Una de las preguntas más interesantes que he leído aquí desde hace un tiempo. Una verdadera revelación. Cuenta conmigo para volver a abrir.
Agnel Kurian

Respuestas:

308

De Wikipedia :

Los estudios de IBM en la década de 1990 sugieren que las computadoras generalmente experimentan aproximadamente un error inducido por rayos cósmicos por 256 megabytes de RAM por mes. [15]

Esto significa una probabilidad de 3.7 × 10 -9 por byte por mes, o 1.4 × 10-15 por byte por segundo. Si su programa se ejecuta durante 1 minuto y ocupa 20 MB de RAM, entonces la probabilidad de falla sería

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

La comprobación de errores puede ayudar a reducir las consecuencias de la falla. Además, debido al tamaño más compacto de los chips como comentó Joe, la tasa de falla podría ser diferente de lo que era hace 20 años.

kennytm
fuente
10
Más importante aún, el tamaño de la característica del chip para CPU en 1995 era de alrededor de 0,35 µm o 350 nm. Ahora es 1/10 de ese tamaño a 35 nm.
Joe Koberg el
18
¿Es posible que en lugar de reducir el riesgo, la disminución del tamaño aumentaría el riesgo ya que tomaría menos energía cambiar el estado de cada bit?
Robert
63
El tamaño reducido definitivamente aumenta el riesgo. Los procesadores reforzados para vehículos espaciales utilizan tamaños de características muy grandes para evitar los efectos de los rayos cósmicos.
Joe Koberg el
22
No solo los rayos cósmicos, los isótopos radiactivos en los materiales utilizados en el chip son un problema mucho mayor. Los fabricantes hacen todo lo posible para asegurarse de que el silicio, la soldadura, la encapsulación, etc. no contengan ningún emisor alfa o beta.
Martin Beckett
14
¡Guauu! Esto significa que aproximadamente 1 byte en mi PC se corrompe cada dos días.
Stefan Monov
91

Al parecer, no es insignificante. De este artículo de New Scientist , una cita de una solicitud de patente de Intel:

"Se han producido bloqueos informáticos inducidos por rayos cósmicos y se espera que aumenten con la frecuencia a medida que los dispositivos (por ejemplo, transistores) disminuyan de tamaño en los chips. Se prevé que este problema se convierta en un importante limitador de la confiabilidad de la computadora en la próxima década".

Puedes leer la patente completa aquí .

ire_and_curses
fuente
77
¿Por qué aumentan con una disminución en el tamaño del chip? Seguramente un objeto más pequeño tiene menos probabilidades de ser golpeado por un rayo (es decir, comparar tirar una pelota de tenis contra una pared, o tirarla en un sello)
Jonathan.
77
Porque a medida que el tamaño de los componentes se reduce, se vuelven mucho más sensibles a los impactos de rayos cósmicos.
ire_and_curses
44
Sí, más pequeño es menos probable que sea golpeado, pero es más probable que el golpe afecte al estado.
John Hascall
2
@ire_and_curses [cita requerida]
Anko
8
@ Anko: es algo obvio. A medida que un componente dado se hace más pequeño, necesita menos voltaje y menos carga para establecer un bit. Eso lo hace más sensible a ser lanzado con energía del espacio exterior. Sin embargo, aquí hay una cita para usted: a medida que los dispositivos de memoria LSI se vuelven más pequeños, se vuelven más sensibles a las fallas suaves inducidas por la radiación nuclear.
ire_and_curses
55

Nota: esta respuesta no se trata de física, sino de errores de memoria silenciosa con módulos de memoria no ECC. Algunos de los errores pueden provenir del espacio exterior y otros, del espacio interior del escritorio.

Hay varios estudios de fallas de memoria ECC en grandes granjas de servidores como clústeres CERN y centros de datos de Google. El hardware de clase de servidor con ECC puede detectar y corregir todos los errores de un solo bit, y detectar muchos errores de varios bits.

Podemos suponer que hay muchas computadoras de escritorio que no son ECC (y teléfonos inteligentes móviles que no son ECC). Si verificamos en los documentos las tasas de error corregibles por ECC (bits de bits únicos), podemos conocer la tasa de corrupción de memoria silenciosa en la memoria no ECC.

Entonces, si el programa tiene un gran conjunto de datos (varios GB), o tiene una alta velocidad de lectura o escritura de memoria (GB / so más), y se ejecuta durante varias horas, entonces podemos esperar hasta varios cambios de bits silenciosos en el hardware del escritorio. Memtest no puede detectar esta tasa, y los módulos DRAM son buenos.

El clúster largo se ejecuta en miles de PC que no son ECC, como la computación de cuadrícula de Internet BOINC siempre tendrá errores de cambios de bits de memoria y también de errores silenciosos de disco y red.

Y para máquinas más grandes (10 miles de servidores) incluso con protección ECC contra errores de un solo bit, como vemos en el informe de Sandia 2012, puede haber cambios de doble bit todos los días, por lo que no tendrá la oportunidad de ejecutar paralelos de tamaño completo programa durante varios días (sin puntos de control regulares y reinicio desde el último punto de control correcto en caso de doble error). Las máquinas enormes también recibirán cambios de bits en sus cachés y registros de CPU (disparadores de chips tanto arquitectónicos como internos, por ejemplo, en la ruta de datos ALU), porque no todos están protegidos por ECC.

PD: Las cosas serán mucho peores si el módulo DRAM es malo. Por ejemplo, instalé una nueva DRAM en la computadora portátil, que murió varias semanas después. Comenzó a dar muchos errores de memoria. Lo que obtengo: la computadora portátil se cuelga, Linux se reinicia, ejecuta fsck, encuentra errores en el sistema de archivos raíz y dice que desea reiniciar después de corregir los errores. Pero en cada próximo reinicio (hice alrededor de 5-6 de ellos) todavía se encuentran errores en el sistema de archivos raíz.

osgx
fuente
99
El material adicional de BH 2011: "Bitsquatting secuestro DNS sin explotación" media.blackhat.com/bh-us-11/Dinaburg/... listas moderno multi-GB DRAM para tener alrededor 1-30000 FIT / Mbit (menos de 100 horas entre errores por cada 128 MB). El documento también enumera los artículos que concluyen que la mayoría de los errores suaves son de radiación, casi todos los casos, de rayos cósmicos, y algunos casos de emisores alfa dentro de la PC. Los autores de BH experimentaron y obtuvieron 50000 accesos a dominios, con 1 bit cambiado de sitios populares
osgx
Felicitaciones por agregar más estudios recientes aquí. Dada la dinámica de la votación SO y cómo se acumulan con el tiempo, es lamentablemente difícil tener una presentación actualizada sobre este tema que se destaque (aquí).
Fizz
Tuvimos un problema similar. No hicimos ningún estudio exacto, pero tuvimos algunos volcados bruscos con volteos de bits visibles. Verificamos esos cambios de bit y resultó que estaban en la sección de código. Comparamos con lo que debería estar allí y no parecía una modificación deliberada (es decir, las instrucciones resultantes no tenían mucho sentido). Al final tuvimos una aplicación simple, que comparó volcados de memoria contra versiones lanzadas (archivadas) y filtró tales casos. Curiosamente, creo que la mayoría de estos casos provienen de Irán, Arabia y creo que un país más de América del Sur (no lo recuerdo ahora).
GiM
2
En el documento de Google, se parece más a un caso de que algo de RAM es mala. Aproximadamente un tercio de las máquinas y más del 8% de los DIMM de nuestra flota vieron al menos un error corregible por año. Nuestras tasas de errores corregibles por DIMM se traducen en un promedio de 25,000–75,000 FIT (fallas en el tiempo por billón de horas de operación) por Mbit y un rango medio de FIT de 778 - 25,000 por Mbit (mediana para DIMM con errores), mientras que estudios anteriores reportan 200-5,000 FIT por Mbit. El número de errores corregibles por DIMM es muy variable, y algunos DIMM experimentan una gran cantidad de errores, en comparación con otros.
vartec
31

Wikipedia cita un estudio de IBM en los años 90 que sugiere que "las computadoras suelen experimentar un error inducido por rayos cósmicos por 256 megabytes de RAM por mes". Desafortunadamente, la cita fue a un artículo en Scientific American, que no dio más referencias. Personalmente, encuentro que ese número es muy alto, pero quizás la mayoría de los errores de memoria inducidos por los rayos cósmicos no causan ningún problema real o notable.

Por otro lado, las personas que hablan de probabilidades cuando se trata de escenarios de software generalmente no tienen idea de lo que están hablando.

JesperE
fuente
77
La probabilidad de que un bit se voltee debe multiplicarse por la probabilidad de que el bit tenga un efecto notable en el programa. Supongo que la segunda probabilidad es mucho más baja de lo que piensas.
Mark Ransom
2
@ Mark: los programas informáticos típicos no tienen ese tipo de tolerancia a fallos incorporada. Un error de un solo bit en el código del programa probablemente bloqueará el programa si se ejecuta el código roto.
Robert Harvey
75
Sí, pero la mayor parte de la memoria contiene datos, donde el cambio no será tan visible.
zoul
34
@zoul. jajaja en 'visiblp', pero si e = 1100101 yp = 1110000, entonces eres la desafortunada víctima de 3 bit flips!
PaulG
10
@Paul: o un toque de dedo.
mpen
30

Bueno, los rayos cósmicos aparentemente causaron el mal funcionamiento de la electrónica en los automóviles Toyota, por lo que diría que la probabilidad es muy alta :)

¿Los rayos cósmicos realmente están causando problemas con Toyota?

Kevin Crowell
fuente
23
"Los reguladores federales están estudiando si la aceleración repentina en Toyotas está relacionada con los rayos cósmicos". Es por eso que nunca debe dar a los reguladores federales poder sobre su vida.
13
Supongo que la teoría aquí es que los rayos cósmicos están volteando pedazos en cerebros más viejos que causan un mal funcionamiento y presionan el pedal incorrecto.
Knox
16
"Aparentemente"? Yo diría que es una suposición descabellada en este momento. Mi propia conjetura es que este fenómeno es el resultado de esa vieja pesadilla de los sistemas integrados (en realidad, los sistemas informáticos más complejos): la condición de la carrera.
Michael Burr
77
@Knox: ¡Saca tu viejo sombrero de papel de aluminio, es útil!
3
Puede que no sea una broma. He visto cosas realmente extrañas como esas suceder antes. No es tan raro como la mayoría de la gente piensa.
Brian Knoblauch el
25

Con ECC puede corregir los errores de 1 bit de los rayos cósmicos. Para evitar el 10% de los casos en los que los rayos cósmicos provocan errores de 2 bits, las celdas de ECC generalmente se entrelazan sobre chips, por lo que no hay dos celdas una al lado de la otra. Por lo tanto, un evento de rayos cósmicos que afecta a dos células dará como resultado dos errores corregibles de 1 bit.

Estados del Sol: (Parte No. 816-5053-10 de abril de 2002)

En términos generales, los errores suaves de rayos cósmicos ocurren en la memoria DRAM a una velocidad de ~ 10 a 100 FIT / MB (1 FIT = 1 dispositivo falla en mil millones de horas). Por lo tanto, un sistema con 10 GB de memoria debe mostrar un evento ECC cada 1,000 a 10,000 horas, y un sistema con 100 GB mostrará un evento cada 100 a 1,000 horas. Sin embargo, esta es una estimación aproximada que cambiará en función de los efectos descritos anteriormente.

3 revoluciones
fuente
17

Los errores de memoria son reales, y la memoria ECC ayuda. La memoria ECC implementada correctamente corregirá errores de un solo bit y detectará errores de doble bit (detendrá el sistema si se detecta dicho error). Puede ver esto en la frecuencia con la que la gente se queja de lo que parece ser un problema de software que se resuelve ejecutando Memtest86 y descubriendo mala memoria. Por supuesto, una falla transitoria causada por un rayo cósmico es diferente a una pieza de memoria que falla constantemente, pero es relevante para la pregunta más amplia de cuánto debe confiar en que su memoria funcione correctamente.

Un análisis basado en un tamaño residente de 20 MB puede ser apropiado para aplicaciones triviales, pero los sistemas grandes tienen rutinariamente múltiples servidores con grandes memorias principales.

Enlace interesante: http://cr.yp.to/hardware/ecc.html

Desafortunadamente, el enlace de Corsair en la página parece estar muerto.

janm
fuente
Los bitflips de rayos cósmicos pueden no estar distribuidos uniformemente, particularmente si incluimos tormentas solares bajo el paraguas de "eventos de rayos cósmicos". Si tiene dos o más bits de bits dentro del mismo byte, el ECC típico no podrá corregir el error.
tobixen
@tobixen Detectar un error de doble bit es mejor que continuar ejecutándose con datos incorrectos. El siguiente paso después de ECC es Chipkill con duplicación DIMM ...
enero
13

Este es un problema real, y es por eso que la memoria ECC se usa en servidores y sistemas integrados. Y por qué los sistemas de vuelo son diferentes de los basados ​​en tierra.

Por ejemplo, tenga en cuenta que las piezas de Intel destinadas a aplicaciones "integradas" tienden a agregar ECC a la hoja de especificaciones. Carece de un Bay Trail para una tableta, ya que haría la memoria un poco más cara y posiblemente más lenta. Y si una tableta bloquea un programa cada vez en una luna azul, al usuario no le importa mucho. El software en sí mismo es mucho menos confiable que el HW de todos modos. Pero para los SKU destinados a uso en maquinaria industrial y automotriz, el ECC es obligatorio. Desde aquí, esperamos que el SW sea mucho más confiable, y los errores de alteraciones aleatorias serían un problema real.

Los sistemas certificados según IEC 61508 y estándares similares generalmente tienen pruebas de arranque que verifican que toda la RAM sea funcional (sin bits atascados en cero o uno), así como manejo de errores en tiempo de ejecución que intenta recuperarse de errores detectados por ECC, y a menudo también las tareas de depuración de memoria que pasan y leen y escriben memoria continuamente para asegurarse de que se noten los errores que ocurran.

¿Pero para el software de PC convencional? No es un gran trato. ¿Para un servidor de larga vida? Use ECC y un manejador de fallas. Si un error no corregible mata el núcleo, que así sea. O te vuelves paranoico y usas un sistema redundante con ejecución de paso de bloqueo para que si un núcleo se corrompe, el otro pueda hacerse cargo mientras el primer núcleo se reinicia.

jakobengblom2
fuente
Los bitflips de rayos cósmicos pueden no estar distribuidos uniformemente, particularmente si incluimos tormentas solares bajo el paraguas de "eventos de rayos cósmicos". Una ráfaga repentina puede causar varios cambios de bits dentro de un byte, y los algoritmos ECC no podrán corregir una falla.
tobixen
12

Si un programa es crítico para la vida (matará a alguien si falla), debe escribirse de tal manera que sea a prueba de fallas o se recupere automáticamente de tal falla. Todos los demás programas, YMMV.

Los toyotas son un ejemplo de ello. Di lo que quieras sobre un cable del acelerador, pero no es un software.

Ver también http://en.wikipedia.org/wiki/Therac-25

Robert Harvey
fuente
No importa el software para aceleradores. Los sensores y el cableado de los aceleradores es el punto débil. Mi sensor de posición del acelerador Mitsubishi falló en un generador de números aleatorios ... ¡Sin aceleración involuntaria, pero seguro que no hizo nada bueno para la mezcla de combustible!
Brian Knoblauch el
3
@Brian: Un buen software habría descubierto que los puntos de datos eran discontinuos y concluyó que los datos eran malos.
Robert Harvey
..y luego qué ... Se requieren buenos datos. Saber que es malo no ayuda en nada. No es algo con lo que puedas trabajar mágicamente.
Brian Knoblauch el
3
@Brian: Bueno, por un lado, puedes tomar medidas correctivas en base al conocimiento de que tus datos son malos. Puedes dejar de acelerar, por ejemplo.
Robert Harvey
Sí, puede (y debe) los datos de cheksum. Mejor de principio a fin. Sin embargo, esto solo reduce las posibilidades de corrupción. Imagine que su instrucción "es esto válido" daña el bit en la memoria o en el registro de la CPU justo cuando desea bifurcarse al controlador de errores.
Eckes
11

Una vez programé dispositivos que iban a volar en el espacio, y luego (supuestamente, nadie me mostró ningún documento al respecto, pero se decía que era de conocimiento común en el negocio) podría esperar que los rayos cósmicos induzcan errores todo el tiempo.

erikkallen
fuente
8
Por encima de la atmósfera suceden dos cosas: 1) el flujo total es más alto 2) mucho más viene en forma de partículas pesadas y muy enérgicas (con suficiente energía para volcar un poco en un espacio pequeño).
dmckee --- ex-gatito moderador
Con respecto a las referencias, hay libros (p. Ej., Books.google.com/books?hl=es&lr=&id=Er5_rzW0q3MC ), conferencias (p. Ej., Radecs2015.org , seemapld.org y otros), y artículos en abundancia sobre este tema. . Los rayos cósmicos no son una broma en el sector aeroespacial. Son una de las razones clave por las que muchas naves espaciales usan computadoras endurecidas por rad, la mayoría de las cuales tienen el poder de procesamiento de un horno tostador inteligente moderno.
David Hammen
8

Se considera que los "eventos de rayos cósmicos" tienen una distribución uniforme en muchas de las respuestas aquí, esto puede no ser siempre cierto (es decir, supernovas). Aunque los "rayos cósmicos", por definición (al menos según Wikipedia) provienen del espacio exterior , creo que es justo incluir también tormentas solares locales (también conocido como eyección de masa coronal bajo el mismo paraguas. Creo que podría causar que varios bits se vuelvan dentro de un breve intervalo de tiempo, potencialmente suficiente para corromper incluso la memoria habilitada para ECC.

Es bien sabido que las tormentas solares pueden causar bastantes estragos en los sistemas eléctricos (como el apagón de Quebec en marzo de 1989 ). Es muy probable que los sistemas informáticos también puedan verse afectados.

Hace unos 10 años estaba sentado justo al lado de otro chico, estábamos sentados con cada una de nuestras computadoras portátiles, fue en un período con un clima solar bastante "tormentoso" (sentados en el Ártico, pudimos observar esto indirectamente: muchas auroras boreales para ser visto). De repente, en el mismo instante, nuestras dos computadoras portátiles se estrellaron. Estaba ejecutando OS X y yo estaba ejecutando Linux. Ninguno de los dos estamos acostumbrados a que las computadoras portátiles se estrellen; es algo bastante raro en Linux y OS X. Los errores de software comunes se pueden descartar más o menos ya que estábamos ejecutando en diferentes sistemas operativos (y no sucedió durante un salto) segundo). He llegado a atribuir ese evento a la "radiación cósmica".

Más tarde, la "radiación cósmica" se ha convertido en una broma interna en mi lugar de trabajo. Cada vez que sucede algo con nuestros servidores y no podemos encontrar ninguna explicación para ello, en broma atribuimos la falla a la "radiación cósmica". :-)

tobixen
fuente
7

Más a menudo, el ruido puede dañar los datos. Las sumas de control se usan para combatir esto en muchos niveles; En un cable de datos, generalmente hay un bit de paridad que viaja junto con los datos. Esto reduce en gran medida la probabilidad de corrupción. Luego, en los niveles de análisis, los datos sin sentido generalmente se ignoran, por lo que incluso si alguna corrupción superara el bit de paridad u otras sumas de verificación, en la mayoría de los casos se ignoraría.

Además, algunos componentes están protegidos eléctricamente para bloquear el ruido (probablemente no los rayos cósmicos, supongo).

Pero al final, como han dicho los otros respondedores, hay un bit o byte ocasional que se codifica, y se deja al azar si es un byte significativo o no. En el mejor de los casos, un rayo cósmico revuelve uno de los bits vacíos y no tiene absolutamente ningún efecto, o bloquea la computadora (esto es algo bueno, porque se evita que la computadora haga daño); pero el peor de los casos, bueno, estoy seguro de que te lo puedes imaginar.

Ricket
fuente
Los bitflips de rayos cósmicos pueden no estar distribuidos uniformemente, particularmente si incluimos tormentas solares bajo el paraguas de "eventos de rayos cósmicos". Si tiene dos bits de bits dentro del mismo byte, la comprobación de bits de paridad fallará. Varios bitflips y algoritmos ECC probablemente no podrán corregir una falla.
tobixen
5

He experimentado esto: no es raro que los rayos cósmicos cambien un poco, pero es muy poco probable que una persona observe esto.

Estaba trabajando en una herramienta de compresión para un instalador en 2004. Mis datos de prueba fueron algunos archivos de instalación de Adobe de aproximadamente 500 MB o más descomprimidos.

Después de una tediosa ejecución de compresión y una ejecución de descompresión para probar la integridad, FC / B mostró un byte diferente.

Dentro de ese byte, el MSB había cambiado. También me volteé, preocupándome de tener un error loco que solo aparecería en condiciones muy específicas, ni siquiera sabía por dónde empezar a buscar.

Pero algo me dijo que volviera a hacer la prueba. Lo corrí y pasó. Configuré un script para ejecutar la prueba 5 veces durante la noche. En la mañana habían pasado los 5.

Así que definitivamente fue un cambio de bit de rayos cósmicos.

rep_movsd
fuente
¿Seguro? ¿No podría haber sido una variable no inicializada que nunca obtuvo un valor inicial malo en las pruebas posteriores?
doug65536
Siempre compilo con W3 o W4 en VS: también Rational Purify, no había errores de ese tipo.
rep_movsd
Ah, lo siento, no sabía que esas opciones de compilación y Rational Purify eran completamente infalibles. =)
doug65536
Teniendo en cuenta que el código se puso en producción y se comprimió y descomprimió cientos de GB correctamente, no había señales de un error similar.
rep_movsd
4

Es posible que desee echar un vistazo también al hardware Fault Tolerant.

Por ejemplo, Stratus Technology construye servidores Wintel llamados ftServer que tenían 2 o 3 "placas base" en paso de bloqueo, comparando el resultado de los cálculos. (esto también se hace en vehículos espaciales a veces).

Los servidores Stratus evolucionaron de un chipset personalizado a un bloqueo en el plano posterior.

Un sistema muy similar (pero de software) es el bloqueo VMWare Fault Tolerance basado en el hipervisor.

Eckes
fuente
4

Como punto de datos, esto acaba de suceder en nuestra compilación:

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  - ^

Eso se parece mucho a un pequeño cambio durante una compilación, en un lugar muy significativo en un archivo fuente por casualidad.

No estoy diciendo necesariamente que se trataba de un "rayo cósmico", pero el síntoma coincide.

dascandy
fuente