Отлов ошибок аппаратного уровня.

← →
Проходящий (2011-02-26 00:15) [0]

Доброго времени суток, мастера.
Предыстория: Как то купил дополнительное ОЗУ для одного компьютера, все бы хорошо, но почему то иногда стали зависать программы или выполнять недопустимые ошибки, после чего Win выдавало сообщение об ошибке и различныепрограммы благополучна вылетали в никуда(то бишь закрывалась, иногда с занятой памятью). После того, как ОЗУ было проверено на memtest, которая аоказала наличие ошибок в ОЗУ (битая планка), пришлось ее поменять на новую и все нормализовалось.......

А теперь собственно к тому что стало интересно:
Обычно работая с Try Except Finally используются конструкции следующего вида:
SomeObject := TSomeObject.Create; try //Что-то делаем finally SomeObject.Free end;
И вот у меня возник вопрос. А что если при работающей программе где то в середине кода условно в момент выполнения SomeObject := TSomeObject.Create; создающаяся переменная или объект попадают на битый байт или бит в ОЗУ? При этом либо глобальная программа подвисает, либо аварийно закрывается Windows без освобождения ресурсов...
А кто нибудь пытался отлавливать ошибки на уровне железа? с целью спасти работоспособность программы и скажем возобновить Create, но уже не в "битом" секторе памяти? или более важный вопрос, как сохранить данные программы (БД и т.д.) без потерь основных(например компютер стоит в офисе, работнику поставили ОЗУ, и он работает с базой не подозревая, что может случиться)?
Гипотетически, конструкция может стать:
try SomeObject := TSomeObject.Create; Except Ошибка с ОЗУ? 1. Попробовать выполнить вновь предыдущий оператор, с целью попасть не в "битый" сектор ОЗУ 2. Или вызвать обработчик закрывающий программу, с сохранением аварийных данных на хард с последующим восстановлением информации и т.д. try //Что-то делаем finally SomeObject.Free end; end; Это такое общее представление...А есть ли возможность определить ошибки извне? Интересно Ваше мнение, мастера. С уважением. PS: Может вопрос не в эту ветку форума, но очень интересно стало попытаться найти ответ или как нить понять возможно ли отловить ошибки в ОЗУ (физические)...

← →
clickmaker © (2011-02-26 00:26) [1]

> возможно ли отловить ошибки в ОЗУ (физические)...

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

← →
Inovet © (2011-02-26 00:52) [2]

А если, электричество отключат, или в комп кофий зальётся?
ОЗУ может быть с контролем чётности или с коррекцией ошибок, чтобы завершить всё и поменять. А в программе это смысла не имеет, при предположительном сбое его невозможно разпознать, т.к. после него сама программа распознавания может работать неверно.

← →
Германн © (2011-02-26 00:56) [3]

> И вот у меня возник вопрос. А что если при работающей программе
> где то в середине кода условно в момент выполнения SomeObject
> := TSomeObject.Create; создающаяся переменная или объект
> попадают на битый байт или бит в ОЗУ? При этом либо глобальная
> программа подвисает, либо аварийно закрывается Windows без
> освобождения ресурсов...
> А кто нибудь пытался отлавливать ошибки на уровне железа?
>

Это просто нереально. И дело не столько в железе, сколько в том, что "проверять каждую машинную инструкцию на ошибки с памятью" просто нереально. А иначе такую ошибку не поймать.

← →
Тяни-Толкай (2011-02-26 01:17) [4]

Ошибка в конструкторе - в 99,999% случаев - ошибка программиста, а не битой памяти. А ошибки аппаратного уровня - не прикладного программиста задача. Suum cuique. Вон, в OSI семь уровней, и каждый уровень своими делами занимается, в чужие дела не лезет. Так и битая память - проблема администратора, а не прикладной программы.

Ну представь, потратишь ты десять лет своей жизни, напишешь супер-защищенный текстовый редактор, который на каждый эксепшн будет стучать в бубен, пытаясь отловить гипотетическую ошибку памяти, и, самое коварное - исправлять эту ошибку. Почему коварное? Потому что администратор будет сидеть и думать: если битая память, то почему все программы сбоят, а вот этот текстовый редактор - не сбоит. Нет, все же, проблема не в памяти,- решит админ,- ведь, если бы проблема была в памяти, то сбоили бы все программы без исключения. Кому потом админ будет говорить "спасибо" за запутывание симптомов?

И вообще, неужели так плохо с памятью в королевстве датском, что остро встает вопрос и экономически оправдано написание программ, отлавливающих ошибки с памятью?

← →
Rouse_ © (2011-02-26 02:12) [5]

По факту аппаратную ошибку проверкой конструктором обьектов не найдешь :) Даж try не поможет, SEH фрейм как ни как тож в памяти сидит, уедет верхушка стека и ищи свищи.
Можно конечно поиграться с резервироваинем физпамяти под процесс через AWE (собственно защита Vista была так и сломана - процесс забирал себе всю физпамять, вытесняя реальные данные в своп, откуда они уже изымались обычным способом :)
Можешь с ним поиграться, тут я приводил код: http://forum.sources.ru/index.php?showtopic=202715

Но только не уверен что на реально битой линейке это заработает...

← →
Германн © (2011-02-26 04:08) [6]

> Можно конечно поиграться с резервироваинем физпамяти под
> процесс через AWE (собственно защита Vista была так и сломана
> - процесс забирал себе всю физпамять, вытесняя реальные
> данные в своп, откуда они уже изымались обычным способом
> :)
>

Извращенец!
Ну, конечно "специфика работы". Я понимаю. :)

← →
Anatoly Podgoretsky © (2011-02-26 11:20) [7]

> Германн (26.02.2011 00:56:03) [3]

Это реально - ECC
Проверен будет каждый байт, только ошибку все равно на пользовательском
уровне не поймать.

← →
Inovet © (2011-02-26 11:44) [8]

> [7] Anatoly Podgoretsky © (26.02.11 11:20)
> ошибку все равно на пользовательском уровне не поймать.

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

← →
Tag (2011-02-26 12:44) [9]

>>для того чтобы всё не упало, корректно завершить работу

Когда глючит память, корректно завершить работу вряд ли удастся.
Даже если удастся, то это может оказаться еще хуже.
Где-то там, внутри, остались неуловимые катастрофические баги.
До поры, до времени.
И даже смена планок памяти не поможет.
Баги уже есть.
На винте.
И никуда не денутся.
До поры, до времени.
До поры...
До времени...

← →
Inovet © (2011-02-26 12:47) [10]

> [9] Tag (26.02.11 12:44)
> Когда глючит память, корректно завершить работу вряд ли удастся.

ECC сделает эту возможность на много порядков более вероятной

← →
Брю (2011-02-26 13:25) [11]

>Inovet © (26.02.11 12:47) [10] ECC сделает эту возможность на много порядков более вероятной

О как, возможность коррекции сбоя в одном бите - это уже "увеличение надежности на много порядков"?

Что-то мне подсказывает, что при одном избыточном бите на один байт вероятность возникновения сбоя уменьшится на 1/8, что даст 12,5% увеличения надежности.

Хотя, впрочем, блондинки дают 50%, чет/нечет.

← →
Inovet © (2011-02-26 13:32) [12]

> [11] Брю (26.02.11 13:25)
> О как, возможность коррекции сбоя в одном бите - это уже
> "увеличение надежности на много порядков"?

Это что за цитата в кавычках? Твоя? Я о другом говорил, потрудись перечитать.

> [10] Inovet © (26.02.11 12:47)

← →
sniknik © (2011-02-26 13:59) [13]

> возможность коррекции сбоя в одном бите
какая коррекция? ты о чем?

> при одном избыточном бите на один байт вероятность возникновения сбоя уменьшится на 1/8, что даст 12,5% увеличения надежности.
это не избыточный бит информации, типа для восстановления данных, это контроль четности, для проверки памяти и возбуждения ошибки "на раннем этапе".
т.е. прочитали откуда то данные, после начинаем писать на диск, а вместо записи получили ексепт типа "ошибка памяти, четность не совпадает".
или начинаем выполнять код, комп читает очередную команду, и вместо выполнения ставшей неопределенной, потенциально опасной, оп - "ошибка памяти, четность не совпадает".

> Хотя, впрочем, блондинки дают 50%, чет/нечет.
блондинки правы, для одного байта возможность определить "битость" памяти = 50%. если оценивать систему в целом там конечно будут другие цифры.

← →
RWolf © (2011-02-26 14:10) [14]

> sniknik © (26.02.11 13:59) [13]

> это не избыточный бит информации, типа для восстановления
> данных

вообще-то ECC — это error-correcting code.

← →
sniknik © (2011-02-26 14:18) [15]

> вообще-то ECC — это error-correcting code.
серьезно? никогда не воспринимал его так. и как он одним битом корректирует 8?

← →
RWolf © (2011-02-26 14:20) [16]

> и как он одним битом корректирует 8?

не одним, а четырьмя; см. «код Хэмминга».

← →
sniknik © (2011-02-26 14:21) [17]

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

← →
sniknik © (2011-02-26 14:24) [18]

> не одним, а четырьмя;
хм во время моего изучения этого, это был 1 бит в добавок к 8... видать память реально, и серьезно подешевела...
осталось еще 4 добавить и будет полное зеркало (+ экономия на расчетах, + из-за этого ускорение). :)

> sniknik © (26.02.11 14:21) [17]

исправляются любые единичные ошибки — самый типичный случай.
если одновременно поменяются два соседних бита, такое код испрваить не сможет.

> [17] sniknik © (26.02.11 14:21)
> а название это маркетинговый ход

Сейчас может быть больше так и есть, но раньше из-за низкой надёжности памяти, когда контроль чётности практически везде ставили, ECC был настоящим, да и сейчас наверное есть такие. Потом уже когда надёжность повысилась контроль почти везде убрали, вот может и стали называть его ECC.
Вот нашёл
http://www.cyberguru.ru/hardware/memory/memory-modules-faq-page6.html

> Inovet (26.02.2011 11:44:08) [8]

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

> Брю (26.02.2011 13:25:11) [11]

Во первых контролируют не 8, а 32 бита.
А во вторых так вероятность не считают, простым делением на N

> sniknik (26.02.2011 14:18:15) [15]

Для восстановления используется 7 бит, корректируют методом простой инверсии
бита.
Алгоритм называется код Хемминга.
По теории надежность восзрастает на много порядков, до появлявления
неустранимой ошибки.

> sniknik (26.02.2011 14:24:18) [18]

Там принцип другой, и конечно не четырьмя, а пятью битами, для 8 бит данных

> Anatoly Podgoretsky © (26.02.11 16:18) [24]

откуда информация?
про 8+4 с восстановлением одиночной ошибки знаю, про 8+5 — не слышал.

> RWolf (26.02.2011 17:16:25) [25]

Для указания от 0 до 8 нужно четыре бита, плюс один бит четности, без этого
восстановление не возможно.
Основы кода Хемминга

Отлов ошибок аппаратного уровня. Найти похожие ветки