Битовые утечки при записи данных на диск

Доброго дня форумчане!
Сорри если оффтоп но... Пишу в консольке на C++ (MSVCE 2010) различные движки по расчетам и тут столкнулся с опасной проблемой.
При записи на диск искажаются данные на один бит, где то один раз на 10⁹ - 10¹¹ данных. Бит просто "теряется" (был 1 стал 0 или наоборот) , соответственно данные уже не верны, что приводит к нулю все проделанную работу.
Из исследованного:
Бит теряется при записи как в поток текстового значения переменных (типа fileout << a[i] << endl;)
Так и при записи в двоичном виде (типа fileout.write(reinterpret_cast<char*>(a),size*sizeof(a[0]));)
Замечено, что данные в памяти верные, т.к. были пойманы моменты при повторном выводе из того же массива все данные были записаны корректно.
Ошибка не зависит от винчестера на который данные были записаны (были записи на 3 различных винта, один из которых рейд массив).
Чаще всего теряется один из старших битов (типа 24-й бит в unsigned long или 24-й в unsigned long long). Других потерянных бит не замечено.
Термин "потерянный" возможно применяю в данном случае не верно. Т.к. заметно искажение только при его инвертировании. Соответственно если был сбой и он вместо 1 записал сбойную 1 - этого я не найду.
Система молчит про контроль целостности данных. Винт тоже. У винтов и рейда все показатели в порядке (блоки не сыпятся, SMART в порядке).

Сталкивался ли кто с подобным? В чем может быть проблема?

В ближайшем будущем хочу переустановить систему и MSVCE 2013. Но не уверен, что система виновата.
Кто что подскажет?

1

Petrolion, Evg, заменил <<30 на <<29, запустил, на экране

Array at address (0x80000040). Proc: 3

и крутится колесико (типа думает)
это хорошо или плохо)?

Добавлено через 1 минуту
...причем жестко так думает - даже диспетчер задач не могу вызывать... все 4 ядра что ли захавал)?

Добавлено через 51 секунду
...чуть чуть отлип, написал

Table asc ready. Read: 0

Добавлено через 6 минут
...еще малек подумал и написал 1 после нуля)

1

Сообщение от vxg и крутится колесико (типа думает)

Я не знаю, что такое "крутится колёсико". Если процесс исполняется и курсор это подсвечивает, то наверное это нормально. Программа-то явно долго работает. Но она не может захватить все 4 ядра, т.к. однопточная

1

Evg, вот поэтому и удивляет жесткое залипание. может выделение триллионов байт памяти вызывает такой тупняк)?

1

vxg, если собирать этот код на 32 битах, то появляется вот такое предупреждение (рапортует gcc):

iteration 536870911u invokes undefined behavior

На этот код:
Я думаю, в твоем случае дело именно в этом.

1

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

Добавлено через 14 минут
DrOffset, странно, у меня почему то ничего не выводит. Можно узнать версию и параметры запуска?
У меня 4.9.3 и запускал вот так Так же пробовал добавлять -fsanitize=undefined, так же безрезультатно, вывод чист.

1

DrOffset, собираю 64 бит. сейчас молотит. пишет строки вроде

Table ... ready. Read: ...

и еще разок написал

Array at address (0x80000040). Proc: 1

это хорошо все или плохо я не понял)?

1

Правда, выкидывает исключение std::bad_array_new_length, так как ( 1 << 30 ) * 4 получается 4 гб.

1

Toshkarik,
Версия

gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)

Код из поста ТС.

Добавлено через 2 минуты

Сообщение от vxg это хорошо все или плохо я не понял)?

Насколько я понял - это нормально.

1

DrOffset, а что скажет при ошибке?

1

Сообщение от vxg а что скажет при ошибке?

Error at adr ....

и т.д.

2

DrOffset, как Вы его смогли собрать? Там ведь винудзный код, а у Вас, как я понимаю, RedHat.

Я, если честно, тоже, как и мой компилятор, не вижу здесь переполнения. При i = 536870911, сумма i + k будет равна 587202559.

0

Сообщение от Evg Но она не может захватить все 4 ядра, т.к. однопточная

лагал своп вплоть до потери реакции на действия пользователя. побоялся что запорет все к чертям. снизил размер через <<28 оставил на 12 ч тест. теперь не лагает, первые строки выплюнул почти мгновенно.

0

Сообщение от Toshkarik как Вы его смогли собрать?

Ну что ж я, безрукий что ли? Выбросил и заменил виндузное на аналоги. Сути это все равно не меняет. Рассматриваемый код я не трогал.

Сообщение от Toshkarik если честно, тоже, как и мой компилятор, не вижу здесь переполнения.

На самом деле я тоже не вижу. Но должен был поделиться наблюдением.

Добавлено через 10 минут
Toshkarik, вообще это похоже на баг в gcc.

1

DrOffset, возможно, Вы изменили n? Так как при n == ( 1 << 30 ) оно не запускается, так как пытается выделить ровно 4гб памяти.

Добавлено через 1 минуту
DrOffset, там Target Milestone: 4.8.1. У Вас 4.8.3. Вроде, уже пофикшена должна быть бага.

0

Сообщение от Toshkarik возможно, Вы изменили n? Так как при n == ( 1 << 30 ) оно не запускается, так как пытается выделить ровно 4гб памяти.

Нет, не менял. Зачем мне изменять n, да еще создавая при этом UB?

Добавлено через 7 минут

Сообщение от Toshkarik Вроде, уже пофикшена должна быть бага.

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

0

Petrolion, 16 ч теста не выявили никаких ошибок. собирал gcc-4.5.2-tdm64-1

Вложения

System64.rar (1.12 Мб, 3 просмотров)

0

Таки получилось загрузить Debian Live 8.5.0 повыкидывать из кода все лишнее и загрузить QT-Creator.
Малый размер ядра системы позволил увеличить объем массива до 13 гиг.
Уже несколько часов работы без ошибок.
Не верю своему счастью! (Эдак и веру на линукс поменять можно )
В отличии от винды с ядра на ядро задача не перепрыгивает. Но субъективно кажется что выделение того же объема памяти чуть медленнее. (Специально не замерял). Не замечено сильной фрагментации памяти. Винду иногда приходилось перегружать (например при свободной 13 гиг оперативы, не мог выделить даже 8 одним куском).
Погоняю прогу еще сутки на разных ядрах. Если ошибок не будет. Начну издеваться на виндой (апгрейд до 10, переустановка). Если вновь установленная винда опять заглючит, выбор для задачи очевиден. Поставлю второй системой линукс и буду переучиваться под него (я и так нуб в С++ под виндой)

0

Сообщение от Petrolion Не верю своему счастью! (Эдак и веру на линукс поменять можно )

Классическая ошибка, когда делается неверный вывод. С вероятностью 99% отличие идёт не от того, что ты работаешь под линуксом, а от того, что ты использовал другой компилятор, который сгенерировал другой код. Вполне возможно, что gcc оказался более ущербным, чем vc и не смог задействовать какие-то более быстрые операции или учесть какие-то дополнительные особенности. Банально ты мог не подать опции оптимизаций

Мне в общем-то всё равно, но вместо того, чтобы предметно разобраться с ошибкой, ты пошёл по другому пути, хотя я несколько раз говорил о том, что надо делать. Точно так же ты мог собрать свою программу не под MSVC, а под Borland'ом и получить другой код, на котором ошибка бы не воспроизводилась. Либо вообще собрать под MSVC с другими опциями компилятора

3

Можете попробовать программу Prime95, есть и под linux и под win. Её тест стабильности достаточно неплохо проверяет систему. Причем у меня на gentoo она находила ошибку через несколько часов, в то время как на win могла сутками крутиться. Если она найдет ошибку, то проблема в железе ( в крайнем случае в микрокоде ), а не в ОС.

Кстати, к слову о микрокодах. Вполне возможно, что debian обновил микрокод при запуске и пофиксил какой либо баг.

0

Сообщение от Evg Либо вообще собрать под MSVC с другими опциями компилятора

пробовал другие опции и другой MSVC. Результат тот же на моей системе. Другой компилятор не пробовал. (Чуть позже QT виндовым попробую)
Не хочу обновляться до 10 винды, но ради эксперимента сделаю. И попробую все протестить (при тех же опциях компилятора). Резльтат обязательно выложу сюда. Если все нормально будет - снесу и чистую семерку поставлю. Моей винде уже года четыре. И за виндами замечено накопление багов с годами.
Не хочу создавать мифы. Всегда опираюсь на "опыт - сын ошибок трудных"

Добавлено через 1 минуту
Toshkarik,

Сообщение от Toshkarik Вполне возможно, что debian обновил микрокод при запуске и пофиксил какой либо баг.

он такое может?!

Добавлено через 1 минуту
тогда при возврате в винду ошибка должна исчезнуть... проверю.

0