Космические лучи: какова вероятность того, что они повлияют на программу?


546

Я снова был в обзоре проекта и столкнулся с утверждением, что вероятность того или иного сценария «меньше, чем риск космических лучей», влияющих на программу, и мне пришло в голову, что я понятия не имею, что это такое вероятность есть.

«Поскольку 2 -128 - это 1 из 340282366920938463463374607431768211456, я думаю, что мы вправе использовать наши шансы здесь, даже если эти вычисления отклоняются в несколько миллиардов раз ... Мы подвергаемся большему риску космических лучей, чтобы облажайся, я верю.

Этот программист прав? Какова вероятность попадания космического луча в компьютер и повлиять на выполнение программы?


42
«Выигрышные лотереи: какова вероятность того, что они повлияют на программу?»
Kennytm

27
Частично это зависит от того, где выполняется программа и насколько хорошо она защищена. На Земле поток космических лучей намного ниже, чем в глубоком космосе или даже на околоземной орбите. Например, космический телескоп Хаббл создает необработанные изображения, пронизанные следами космических лучей.
Адам Холлидж

89
Означает ли это, что с этого момента, когда кто-то в следующий раз спрашивает о finallyблоках, мы должны будем квалифицировать его как «всегда выполняется, кроме случаев, когда программа завершается, или если на нее попадает космический луч»?
Скаффман

72
Работая над прототипом детектора частиц много лет назад, я запрограммировал его напечатать "ай!" каждый раз, когда он попал под космический луч. Хорошие времена ...
бета

8
На один из самых интересных вопросов, которые я читал здесь некоторое время. Настоящий откровением. Положитесь на меня, чтобы открыть снова.
Агнель Курьян

Ответы:


308

Из Википедии :

Исследования, проведенные IBM в 1990-х годах, показывают, что компьютеры обычно испытывают примерно одну ошибку, вызванную космическими лучами, на 256 мегабайт оперативной памяти в месяц. [15]

Это означает вероятность 3,7 × 10 -9 на байт в месяц или 1,4 × 10 -15 на байт в секунду. Если ваша программа работает в течение 1 минуты и занимает 20 МБ ОЗУ, то вероятность сбоя будет

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

Проверка ошибок может помочь уменьшить последствия сбоя. Кроме того, из-за более компактного размера чипов, как прокомментировал Джо, частота отказов может отличаться от той, что была 20 лет назад.


10
Что еще более важно, размер чипа для процессоров в 1995 году составлял около 0,35 мкм или 350 нм. Это сейчас 1/10 этого размера при 35 нм.
Джо Коберг

18
Возможно ли, что вместо уменьшения риска уменьшенный размер увеличит риск, поскольку для изменения состояния каждого бита потребуется меньше энергии?
Роберт

63
Уменьшенный размер определенно увеличивает риск. Закаленные процессоры для космических аппаратов используют очень большие размеры элементов, чтобы избежать влияния космических лучей.
Джо Коберг

22
Не только космические лучи, но и радиоактивные изотопы в материалах, используемых в чипе, представляют собой гораздо большую проблему. Производители делают все возможное, чтобы кремний, припой, инкапсуляция и т. Д. Не содержали альфа- или бета-излучатели.
Мартин Беккет

14
Вот Это Да! Это означает, что примерно 1 байт на моем компьютере повреждается каждые два дня.
Стефан Монов

91

Видимо, немаловажно. От этой статьи New Scientist , цитата из заявки на патент Intel:

«Произошли сбои компьютеров, вызванные космическими лучами, и ожидается, что они будут увеличиваться с частотой, поскольку устройства (например, транзисторы) уменьшаются в размерах микросхем. Предполагается, что эта проблема станет основным ограничителем надежности компьютеров в следующем десятилетии».

Вы можете прочитать полный патент здесь .


7
Почему они увеличиваются с уменьшением размера чипа? Конечно, меньший объект с меньшей вероятностью попадет под луч (то есть сравните бросание теннисного мяча в стену с броском в штамп)
Джонатан.

7
Потому что с уменьшением размеров компонентов они становятся намного более чувствительными к попаданиям космических лучей.
ire_and_curses

4
Да, меньшие равны меньше вероятности попадания, но более вероятно, что попадание повлияет на состояние.
Джон Хэсколл

2
@ire_and_curses [нужна цитата]
Anko

8
@ Анко - Это вроде бы очевидно. Поскольку данный компонент становится меньше, ему нужно меньше напряжения и меньше заряда, чтобы установить немного. Это делает его более чувствительным к взрыву энергией из космоса. Однако вот вам цитата: по мере того как устройства памяти LSI становятся меньше, они становятся более чувствительными к программным сбоям, вызванным ядерным излучением.
ire_and_curses

55

Примечание: этот ответ не о физике, а о тихих ошибках памяти с модулями памяти не-ECC. Некоторые ошибки могут исходить из космоса, а некоторые - из внутреннего пространства рабочего стола.

Существует несколько исследований сбоев памяти ECC на крупных фермах серверов, таких как кластеры CERN и центры обработки данных Google. Аппаратное обеспечение серверного класса с ECC может обнаруживать и исправлять все однобитовые ошибки, а также обнаруживать множество многобитовых ошибок.

Мы можем предположить, что есть много настольных компьютеров не-ECC (и мобильных смартфонов не-ECC). Если мы проверим документы на наличие ошибок, исправляемых с помощью ECC (единичные битовые отрывки), мы сможем узнать частоту незаметных повреждений памяти в не-ECC памяти.

  • Крупномасштабное исследование CERN 2007 «Целостность данных» : поставщики заявляют « Коэффициент ошибок по битам 10–12 для их модулей памяти », « наблюдаемая частота ошибок на 4 порядка ниже ожидаемой ». Для задач с интенсивным использованием данных (8 ГБ / с чтения памяти) это означает, что переворот в один бит может происходить каждую минуту (10 -12 поставщиков BER) или один раз в два дня (10 -16 BER).

  • В статье Google 2009 года «Ошибки DRAM в дикой природе: крупномасштабное полевое исследование» говорится, что может быть до 25000-75000 однобитных FIT на Мбит ( сбои во времени на миллиард часов ), что равно 1 - 5 битам. ошибок в час для 8ГБ оперативной памяти после моих расчетов. В документе говорится то же самое: « означает исправимые ошибки в 2000–6000 за ГБ в год ».

  • Отчет Sandia 2012 года «Обнаружение и исправление искажения данных без вывода сообщений для крупномасштабных высокопроизводительных вычислений» : «двухбитные перевороты считались маловероятными», но в плотном Cray XT5 ORNL они «со скоростью один в день для 75 000+ DIMM» с ECC. И однобитовые ошибки должны быть выше.

Таким образом, если программа имеет большой набор данных (несколько ГБ) или имеет высокую скорость чтения или записи в память (ГБ / с или более) и работает в течение нескольких часов, то мы можем ожидать до нескольких тихих переключений битов на настольном оборудовании. Эта скорость не обнаруживается в memtest, и модули DRAM хороши.

Длинный кластер работает на тысячах компьютеров, не принадлежащих ECC, как, например, глобальные сетевые вычисления BOINC, всегда будут иметь ошибки из-за скачков памяти, а также из-за ошибок диска и сети.

А для больших машин (10 тысяч серверов) даже с защитой ECC от однобитных ошибок, как мы видим в отчете Sandia за 2012 год, каждый день могут происходить двухбитовые перевороты, поэтому у вас не будет возможности запустить полноразмерную параллель программа на несколько дней (без регулярной контрольной точки и перезапуска с последней хорошей контрольной точки в случае двойной ошибки). Огромные машины также получат перевороты в своих кэшах и регистрах процессоров (как триггеры архитектурных, так и внутренних чипов, например, в канале данных ALU), потому что не все из них защищены ECC.

PS: все будет намного хуже, если модуль DRAM плохой. Например, я установил новую DRAM в ноутбук, который умер через несколько недель. Это начало давать много ошибок памяти. Что я получаю: ноутбук зависает, linux перезагружается, запускает fsck, находит ошибки в корневой файловой системе и говорит, что хочет сделать перезагрузку после исправления ошибок. Но при каждой следующей перезагрузке (я сделал около 5-6 из них) все еще обнаруживаются ошибки в корневой файловой системе.


9
Дополнительный материал из BH 2011: «Битсквоттинг. Перехват DNS без использования» media.blackhat.com/bh-us-11/Dinaburg/… перечисляет современные DRAM с несколькими ГБ, которые имеют около 10000-30000 FIT / Мбит (менее 100 часов между ошибки на каждые 128МБ). В документе также перечислены статьи, в которых делается вывод о том, что наиболее мягкие ошибки связаны с излучением, почти все случаи - с космическими лучами, а некоторые случаи - с альфа-излучателями внутри ПК. Авторы BH провели эксперименты и получили 50000 обращений к доменам, изменив 1 бит по
сравнению

Слава за добавление более недавних исследований здесь. Учитывая динамику голосования СО и то, как они накапливаются с течением времени, увы, трудно выделить актуальную презентацию по этой теме (здесь).
Fizz

У нас была похожая проблема. Мы не провели точного исследования, но у нас было несколько аварийных дампов с видимыми переворотами. Мы проверили эти биты и оказалось, что они были в разделе кода. Мы сравнили с тем, что должно быть там, и это не выглядело как преднамеренная модификация (т.е. получившиеся инструкции не имели особого смысла). В итоге у нас было простое приложение, которое сравнивало аварийные дампы с (заархивированными) выпущенными версиями и отфильтровывало такие случаи. Интересно, что большинство таких случаев происходило из Ирана, Аравии и еще одной страны из Южной Америки (не помню сейчас).
ГиМ

2
В статье Google это больше похоже на случай, когда некоторое ОЗУ не работает. Около трети машин и более 8% модулей DIMM в нашем автопарке видели как минимум одну исправляемую ошибку в год. Наши коэффициенты исправляемых ошибок на DIMM приводят к среднему значению 25 000–75 000 FIT (сбоев во времени на миллиард часов работы) на Мбит и срединный диапазон FIT 778–25 000 на Мбит (медиана для DIMM с ошибками), в то время как предыдущие исследования сообщают о 200-5000 FIT на Мбит. Количество исправляемых ошибок на модуль DIMM сильно варьируется, при этом некоторые модули DIMM испытывают огромное количество ошибок по сравнению с другими.
Vartec

31

Википедия цитирует исследование, проведенное IBM в 90-х годах, в котором говорится, что «компьютеры обычно испытывают примерно одну ошибку, вызванную космическими лучами, на 256 мегабайт оперативной памяти в месяц». К сожалению, цитата была к статье в Scientific American, которая не давала никаких дальнейших ссылок. Лично я считаю, что это число очень велико, но, возможно, большинство ошибок памяти, вызванных космическими лучами, не вызывают каких-либо реальных или заметных проблем.

С другой стороны, люди, говорящие о вероятностях, когда дело доходит до программных сценариев, обычно не имеют ни малейшего понятия, о чем они говорят.


7
Вероятность переворачивания бита должна быть умножена на вероятность того, что бит окажет заметное влияние на программу. Я предполагаю, что вторая вероятность намного ниже, чем вы думаете.
Марк Рэнсом

2
@Mark: Типичные компьютерные программы не имеют такой встроенной отказоустойчивости. Однобитовая ошибка в программном коде, скорее всего, приведет к аварийному завершению работы программы, если испорченный код будет выполнен.
Роберт Харви

75
Да, но большая часть памяти содержит данные, где переворот не будет таким видимым.
Зул

34
@zoul. lol at 'visiblp', но если e = 1100101 и p = 1110000, то вы несчастная жертва 3- битных сальто!
PaulG

10
@Paul: или одно прикосновение пальца.
mpen

30

Что ж, космические лучи, очевидно, вызвали неисправность электроники в автомобилях Toyota, поэтому я бы сказал, что вероятность очень высока :)

Действительно ли космические лучи вызывают беду у Тойоты?


23
«Федеральные регуляторы изучают, связано ли внезапное ускорение в Тойоте с космическими лучами». Вот почему вы никогда не должны давать федеральным регуляторам власть над своей жизнью.

13
Я предполагаю, что теория заключается в том, что космические лучи переворачивают биты в старых мозгах, заставляя их работать со сбоями и нажимать не ту педаль.
Нокс

16
"По всей видимости"? Я бы сказал, что это дикая догадка на данный момент. Мое собственное дикое предположение состоит в том, что это явление является результатом того старого кошмара встроенных систем (фактически самых сложных компьютерных систем) - состояния гонки.
Майкл Берр

7
@Knox: Получите ваш старый шлем из фольги, то это полезно!

3
Это может быть не шутка. Я видел некоторые странные вещи, подобные тому, что случалось раньше. Не так редко, как думает большинство людей.
Брайан Кноблаух

25

С ECC вы можете исправить 1-битные ошибки космических лучей. Чтобы избежать 10% случаев, когда космические лучи приводят к 2-битным ошибкам, ячейки ECC обычно чередуются по чипам, поэтому две ячейки не находятся рядом друг с другом. Событие космического луча, которое воздействует на две ячейки, приведет к двум исправимым 1-битным ошибкам.

Sun заявляет: (Часть № 816-5053-10 апреля 2002 года)

Вообще говоря, ошибки памяти космических лучей происходят в памяти DRAM со скоростью ~ 10–100 FIT / МБ (1 FIT = 1 отказ устройства за 1 миллиард часов). Таким образом, система с 10 ГБ памяти должна показывать событие ECC каждые 1000–10 000 часов, а система с 100 ГБ будет отображать событие каждые 100–1 000 часов. Однако это приблизительная оценка, которая будет меняться в зависимости от эффектов, описанных выше.


17

Ошибки памяти реальны, и память ECC помогает. Правильно реализованная память ECC исправит однобитовые ошибки и обнаружит двухбитные ошибки (остановка системы при обнаружении такой ошибки.) Это можно увидеть по тому, как регулярно люди жалуются на то, что кажется программной проблемой, которая решается путем запуска Memtest86 и обнаружение плохой памяти. Конечно, временный сбой, вызванный космическим лучом, отличается от постоянно разрушающегося фрагмента памяти, но он имеет отношение к более широкому вопросу о том, насколько вы должны доверять своей памяти для правильной работы.

Анализ, основанный на резидентном размере 20 МБ, может быть подходящим для тривиальных приложений, но большие системы обычно имеют несколько серверов с большой основной памятью.

Интересная ссылка: http://cr.yp.to/hardware/ecc.html

Ссылка Corsair на странице, к сожалению, кажется мертвой.


Бит-флипы космических лучей могут быть неравномерно распределены, особенно если мы включим солнечные бури под зонтиком «события космических лучей». Если вы получили два или более бит-флипов в одном байте, типичный ECC не сможет исправить ошибку.
Tobixen

@tobixen Обнаружение двухбитной ошибки лучше, чем продолжать работу с неверными данными. Следующим шагом после ECC является Chipkill с зеркалированием DIMM ...
Янв

13

Это реальная проблема, и именно поэтому память ECC используется на серверах и встраиваемых системах. И почему летающие системы отличаются от наземных.

Например, обратите внимание, что детали Intel, предназначенные для «встроенных» приложений, как правило, добавляют ECC к спецификации. В Bay Trail для планшета его нет, так как это сделает память немного дороже и, возможно, медленнее. И если планшет вылетает однажды в синюю луну, пользователю это безразлично. Само программное обеспечение намного менее надежно, чем HW в любом случае. Но для SKU, предназначенных для использования в промышленных машинах и автомобилях, ECC является обязательным. С тех пор мы ожидаем, что ПО будет гораздо более надежным, и ошибки от случайных сбоев будут реальной проблемой.

Системы, сертифицированные в соответствии с IEC 61508 и аналогичными стандартами, обычно имеют как тесты загрузки, которые проверяют работоспособность всей оперативной памяти (нет битов, застрявших на нуле или единице), так и обработку ошибок во время выполнения, которая пытается восстановиться после ошибок, обнаруженных ECC, и часто также задачи очистки памяти, которые непрерывно проходят, читают и записывают память, чтобы гарантировать, что любые возникающие ошибки будут замечены.

Но для основного программного обеспечения для ПК? Не так уж и важно. Для долгоживущего сервера? Используйте ECC и обработчик ошибок. Если неисправимая ошибка убивает ядро, пусть будет так. Или вы идете параноиком и используете избыточную систему с пошаговым выполнением блокировки, чтобы, если одно ядро ​​было повреждено, другое могло вступить во владение, пока первое ядро ​​перезагружается.


Бит-флипы космических лучей могут быть неравномерно распределены, особенно если мы включим солнечные бури под зонтиком «события космических лучей». Внезапный всплеск может привести к нескольким бит-флипам внутри байта, и ECC-алгоритмы не смогут исправить ошибку.
Tobixen

12

Если программа жизненно важна (в случае сбоя она кого-то убьет), ее необходимо написать так, чтобы она была либо отказоустойчивой, либо автоматически восстанавливалась после такого сбоя. Все остальные программы, YMMV.

Тойоты являются тому примером. Скажите, что вы будете о кабеле дросселя, но это не программное обеспечение.

Смотрите также http://en.wikipedia.org/wiki/Therac-25


Фигу программное обеспечение для дросселей. Датчики и проводка для дросселей это слабое место. Мой датчик положения дроссельной заслонки Mitsubishi вышел из строя в генератор случайных чисел ... Никакого непреднамеренного ускорения, но он определенно не принес ничего хорошего для топливной смеси!
Брайан Кноблаух

3
@ Брайан: Хорошее программное обеспечение выяснило бы, что точки данных были непостоянны, и пришло бы к выводу, что данные были плохими.
Роберт Харви

... и что потом ... Требуются хорошие данные. Знание, что это плохо, не помогает никому. Не то, что вы можете волшебным образом обойти.
Брайан Кноблаух

3
@ Брайан: Ну, во-первых, вы можете предпринять корректирующие действия, основываясь на знании того, что ваши данные плохие. Вы можете остановить ускорение, например.
Роберт Харви

Да, вы можете (и должны) данные чексум. Лучший сквозной. Однако это только снижает вероятность коррупции. Представьте, что ваша инструкция "is this valid" получает бит, поврежденный в памяти или регистре процессора, только когда вы хотите перейти к обработчику ошибок.
Eckes

11

Однажды я запрограммировал устройства, которые должны были летать в космосе, и тогда вы (предположительно, никто никогда не показывал мне об этом никакой бумаги, но это, как говорили, является общеизвестным в бизнесе), могли ожидать, что космические лучи будут постоянно вызывать ошибки.


8
Над атмосферой происходят две вещи: 1) общий поток выше 2) гораздо больше его поступает в виде тяжелых, очень энергичных частиц (с достаточным количеством энергии, чтобы немного перевернуться в маленьком пространстве).
dmckee --- котенок экс-модератора

Что касается ссылок, есть книги (например, books.google.com/books?hl=en&lr=&id=Er5_rzW0q3MC ), конференции (например, radecs2015.org , seemapld.org и другие) и множество статей по этой теме. , Космические лучи - не шутка в космосе. Они являются одной из ключевых причин того, что многие космические корабли используют радиозащитные компьютеры, большинство из которых имеют вычислительную мощность современной умной тостерной печи.
Дэвид Хаммен,

8

«события космических лучей», как полагают, имеют равномерное распределение во многих ответах здесь, это не всегда может быть правдой (то есть сверхновых). Хотя «космических лучей» по определению (по крайней мере , согласно Википедии) поступает из внешнего пространства, я думаю , что это справедливо также включать местные солнечные бури (ака выброс корональной массы под одной крышей. Я считаю , что это может привести к несколько битов , чтобы перевернуть в пределах короткий промежуток времени, потенциально достаточный для повреждения даже памяти с поддержкой ECC.

Общеизвестно, что солнечные бури могут привести к некоторым разрушениям в электрических системах (например, отключение электроэнергии в Квебеке в марте 1989 года ). Вполне вероятно, что компьютерные системы также могут быть затронуты.

Около 10 лет назад я сидел рядом с другим парнем, мы сидели с каждым из наших ноутбуков, это было в период с довольно «штормовой» солнечной погодой (сидя в Арктике, мы могли наблюдать это косвенно - множество северных сияний увидимся). Внезапно - в один и тот же момент - оба наших ноутбука рухнули. Он работал под управлением OS X, а я - под Linux. Никто из нас не привык к сбоям ноутбуков - это довольно редко встречается в Linux и OS X. Общие ошибки в программном обеспечении могут быть более или менее исключены, поскольку мы работали в разных ОС (и этого не произошло во время прыжка). второй). Я приписал это событие "космическому излучению".

Позже «космическое излучение» стало внутренней шуткой на моем рабочем месте. Всякий раз, когда что-то происходит с нашими серверами, и мы не можем найти никакого объяснения этому, мы в шутку приписываем ошибку "космическому излучению". :-)


7

Чаще всего шум может повредить данные. Контрольные суммы используются для борьбы с этим на многих уровнях; в кабеле данных обычно есть бит четности, который перемещается вместе с данными. Это значительно снижает вероятность коррупции. Затем на уровнях синтаксического анализа бессмысленные данные обычно игнорируются, поэтому, даже если какое-то искажение прошло бит контроля четности или другие контрольные суммы, в большинстве случаев оно будет проигнорировано.

Кроме того, некоторые компоненты электрически экранированы, чтобы блокировать шум (вероятно, не космические лучи, я думаю).

Но, в конце концов, как сказали другие авторы, есть случайный бит или байт, который шифруется, и остается шанс, значительный ли это байт или нет. В лучшем случае, космический луч скремблирует один из пустых битов и не имеет абсолютно никакого эффекта или сбивает компьютер (это хорошо, потому что компьютер защищен от вреда); но в худшем случае, ну, я уверен, вы можете себе представить.


Бит-флипы космических лучей могут быть неравномерно распределены, особенно если мы включим солнечные бури под зонтиком «события космических лучей». Если вы получили два бит-флипа в одном байте, проверка четности завершится неудачно. Несколько битовых клипов и ECC-алгоритмы, вероятно, не смогут исправить ошибку.
Tobixen

5

Я испытал это - космические лучи нередко переворачиваются, но очень маловероятно, чтобы человек это наблюдал.

Я работал над инструментом сжатия для установщика в 2004 году. Моими тестовыми данными были некоторые установочные файлы Adobe размером около 500 МБ или более, распакованные.

После утомительного сжатия и распаковки для проверки целостности FC / B показала один байт другой.

Внутри этого байта MSB перевернулся. Я также перевернулся, опасаясь, что у меня была сумасшедшая ошибка, которая появлялась только в очень специфических условиях - я даже не знал, с чего начать.

Но что-то подсказало мне снова пройти тест. Я запустил это, и это прошло. Я установил скрипт для запуска теста 5 раз за ночь. Утром все 5 прошло.

Так что это определенно был космический луч.


Определенно? Разве это не была неинициализированная переменная, которая никогда не получала неправильное начальное значение в последующих тестах?
doug65536

Я всегда компилирую с W3 или W4 на VS. Также в Rational Purify не было ошибок такого рода.
rep_movsd

Ах, извините, я не знал, что эти опции компилятора и Rational Purify были абсолютно безошибочными. =)
doug65536

Учитывая то, что код был затем запущен в производство и должным образом сжат и распакован на сотни ГБ, признаков подобной ошибки не было.
rep_movsd

4

Возможно, вы захотите взглянуть и на аппаратное обеспечение отказоустойчивости.

Например, Stratus Technology строит серверы Wintel, называемые ftServer, которые имели 2 или 3 «материнские платы» в шаге блокировки, сравнивая результаты вычислений. (это также иногда делается в космических аппаратах).

Серверы Stratus эволюционировали от нестандартного набора микросхем до блокировки на объединительной плате.

Очень похожей (но программной) системой является порог блокировки VMWare Fault Tolerance на основе гипервизора.


4

В качестве точки данных это только что произошло в нашей сборке:

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

Это очень сильно похоже на переворот, происходящий во время компиляции, в очень значительном месте исходного файла случайно.

Я не обязательно говорю, что это был «космический луч», но симптомы совпадают.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.