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

Доброго дня форумчане!
Сорри если оффтоп но... Пишу в консольке на 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

Сообщение от Renji Поставить QtCreator с mingw и проверить ошибку в нем.

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

Сообщение от Renji Загрузиться с лайв-CD Дебиана, sudo apt-get install qt-sdk в консольке, опять-же проверить все в QtCreator. Сразу уточняю, лайв ставит новый софт в оперативку, на хард он ничего не пишет.

Опять же. Если проблема не исчезнет - это гарантированный результат, если исчезнет - это может ничего не значить.

1

Ещё одно наблюдение. В логах из поста #28 дефектными оказались адреса

концовки адресов весьма похожи. Там, где адрес заканчивается на 928, имеем незаконно взведённый 24-й бит, там, где адрес заканчивается на 918, имеем незаконно погашенный 24-й бит. Было бы интересно посмотреть ещё на парочку логов от той программы, сохранится ли там подобная тенденция

Добавлено через 2 минуты
Сразу не заметил лог в 34-м посте (из-за названия Test.zip). Там сия тенденция повторяется

Добавлено через 4 минуты
Зря ты работаешь в большим исходником программы. Его наоборот надо сокращать. В идеале до минимума (т.е. один цикл записи и один цикл проверки)

То, что имеем в печати виртуальные адреса, принципиально ничего не портит. Они отображаются на физические адреса с точностью до страницы (4 килобайт). Т.е. младшие 12 бит виртуального адреса будут совпадать с младшими 12 битами физического адреса

При этом закономерность по адресам наблюдается именно в младших 12 битах, что говорит скорее о проблемах с памятью (контроллер памяти, планки памяти, или что-то типа того). Если бы была проблема с кэшем, то совпадение адресов было бы в пределах 6 бит, исходя из того, что размер линии кэша равен 32 байтам (может там не 32, а 64 или 128, это уже не так важно). Я не знаю точных алгоритмов работы кэша, но по ощущениям они вряд ли работают с точностью до страницы памяти

Добавлено через 11 минут
Если культурно сократишь тест (выкинешь все conio.h), то его можно будет компилировать не только микрософтовским компилятором. Исправить тест в общем-то сможет любой, но проверить можешь только ты, а потому будет лучше, если ты выложишь нормально сокращённый пример, который скомпилируется в любом компиляторе. А потом тебе народ выдаст бинарники, а ты уже будешь смотреть, что из них падает, а что нет. Посмотрев на код падающих и не падающих бинарников в общем-то тоже можно будет увидеть какие-то закономерности

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

1

Сообщение от Evg При этом закономерность по адресам наблюдается именно в младших 12 битах

В 13-ти. Причем если 13-й бит=1 то 24-й бит - устанавливается, а если 13-й бит=0 - то 24-й - гасится.

1

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

1

Сообщение от Evg сигнал с какой-то линии одной шины перебивает сигнал на линии другой шины.

Все-таки, мне имхается, что проблема в микрокоде. Если б что-то перебивало на физическом уровне оно б зависело только от конкретных (может соседних? но не зная разводки не сказать) битов. Да и сама система кэша/памяти не может давать такие артефакты (ошибка только при 0x918 или при 0x928, была б зависимость от одного бита, другие были бы рандомными).

1

Сообщение от avgoor Все-таки, мне имхается, что проблема в микрокоде

Скорее всего в этом случае ошибка бы повторялась стабильно

Сообщение от avgoor Да и сама система кэша/памяти не может давать такие артефакты (ошибка только при 0x918 или при 0x928, была б зависимость от одного бита, другие были бы рандомными)

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

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

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

1

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

...

Сообщение от avgoor (может соседних? но не зная разводки не сказать

Слабо верится, что у амдшников случайно получилось создать активный ПАВ-фильтр (Ну, или на стоячей ЭМ волне) с такими свойствами.

Сообщение от Evg В любом случае мы тут можем только гадать, тем более при постановке диагноза по телефону.

Сообщение от Evg Предметным решением вопроса было бы постепенная замена комплектующих.

+1.

1

Сообщение от avgoor Слабо верится, что у амдшников случайно получилось создать активный ПАВ-фильтр

Это может попросту быть бракованный экземпляр. Или он поломался в процессе работы. Типа в каком-то конденсаторе было постоянно немного большее напряжение, чем положено, и в конце-концов его пробило. Да мало ли чего там может быть

1

UPD: Типичное описание ошибки в микрокоде какое-то такое:
Если через одну команду от MOV EAX [PTR] стоит стоит XOR ECX [PTR] и при этом адрес в ESP делится без остатка на 42, может сброситься какой-то флаг.
Что очень похоже на поведение системы ТС.

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

Сообщение от Evg Это может попросту быть бракованный экземпляр

Может, конечно, но очень маловероятно с такими симптомами.

1

Был чуть занят, но пока решил по совету Renji попробовать под Live-CD Debian откомпилить и запустить код.
Правда С линуксами знаком настолько поверхностно, что просто не пугаюсь их, но и знаниями не обладаю.
Насколько понял, conio.h и Windows.h необходимо убрать (и все с ним связанное).
Но как корректно тормознуть процесс? Как получить номер ядра и зафиксить процесс на конкретном ядре проца?
Уже скачал 8.4 версию KDE и GNOM. Какой интерфейс лучше грузить?

0

Сообщение от Petrolion Как получить номер ядра и зафиксить процесс на конкретном ядре проца?

Гугл №1
Гугл №2

1

Сообщение от Petrolion Но как корректно тормознуть процесс?

Запускаешь программу в консоли, клавишами ctrl-c прибиваешь

Можно, конечно, и под линуксом смотреть. Но если gcc построит немного другой код и ошибка перестанет проявляться, то твою проблему это всё равно не решит.

1

Сообщение от Petrolion Уже скачал 8.4 версию KDE и GNOM. Какой интерфейс лучше грузить?

Лично мне нравится Mate и при переходе на него с Винды никаких проблем возникнуть не должно. Ну, разве что системное меню и часики теперь будут вверху, а не внизу. А вот современный третий GNOME настоятельно не рекомендую - именно под маты в адрес третьего Гнома и появился Mate (форк старого-доброго второго Гнома).

1

Что то странное происходит, уже дошли до другой ОС и даже до выбора DE, которая не нужна для проверки. Вроде уже должно быть понятно, что ошибка не программная, по крайней мере не того уровня, на котором вы ищите.

1

Toshkarik, сейчас речь идет о смене системы как платформы под которым работает код. Чтобы понять, то ли это битая система, то ли совокупность MS Windows + нестабильное железо. Т.к. при проверке самого железа без MS Win ошибок не возникает.
Renji, mate почему-то не захотел грузиться вообще (sha1 проверен). Гном загрузился. (сейчас под ним) Но вот QT-creator не нашел всех файлов для инсталляции:

Где нужно выпрямить руки?

0

Сообщение от Petrolion Где нужно выпрямить руки?

Лайв просит старые версии программ (какие были в момент выхода 8.4), репозиторий пытается отдать новые (какие сейчас в 8.5).
Выполнить sudo apt-get update;sudo apt-get upgrade (качает обновления) или брать 8.5 лайв. 8.5 лайв только сейчас проверил, работает.

Добавлено через 8 минут
UPD И да, проверил как QtCreator работает под Гномом - ну работать то он работает, но Гном как-то странно работает с окнами запущенных программ. Почему-то их удается найти только через alt+tab, а не через список открытых окон вверху (еще раз убеждаюсь что правильно с Гнома свалил).

1

Petrolion, у меня ваш код из поста Битовые утечки при записи данных на диск крашит выбрасывая исключение std::bad_alloc видимо машина хилая)

1

vxg, в релизе поставьте платформу x64. В коде 8 гиг оперативы съедается. Чтобы уменьшить - строчку int n = 1<<30; измените на значение поменьше. Например int n = 1<<29; (4 гига) или int n = 1<<28; (2 гига).

0

Petrolion, я собираю через mingw64 g++ так как ваша сборка зависит от DLL студии. у меня 4 оперативы и 4 подкачка. видимо все отдать не может) попробую уменьшить

0

Сообщение от Petrolion В коде 8 гиг оперативы съедается

Сократи код. Может проблема проявляется задолго до 8 гигов. Типа того, что если поставить полгига, то тоже проявится

0