| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Отлов ошибок аппаратного уровня. [D7, XP]
Проходящий © (2011-02-26 00:15:00)Доброго времени суток, мастера.
Предыстория: Как то купил дополнительное ОЗУ для одного компьютера, все бы хорошо, но почему то иногда стали зависать программы или выполнять недопустимые ошибки, после чего 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: Может вопрос не в эту ветку форума, но очень интересно стало попытаться найти ответ или как нить понять возможно ли отловить ошибки в ОЗУ (физические)...
Германн (2011-02-26 04:08:00) [21]
> Можно конечно поиграться с резервироваинем физпамяти под
> процесс через AWE (собственно защита Vista была так и сломана
> - процесс забирал себе всю физпамять, вытесняя реальные
> данные в своп, откуда они уже изымались обычным способом
> :)
>
Извращенец!
Ну, конечно "специфика работы". Я понимаю. :)
Rouse_ (2011-02-26 02:12:00) [22]По факту аппаратную ошибку проверкой конструктором обьектов не найдешь :) Даж try не поможет, SEH фрейм как ни как тож в памяти сидит, уедет верхушка стека и ищи свищи.
Можно конечно поиграться с резервироваинем физпамяти под процесс через AWE (собственно защита Vista была так и сломана - процесс забирал себе всю физпамять, вытесняя реальные данные в своп, откуда они уже изымались обычным способом :)
Можешь с ним поиграться, тут я приводил код: http://forum.sources.ru/index.php?showtopic=202715
Но только не уверен что на реально битой линейке это заработает...
Тяни-Толкай (2011-02-26 01:17:00) [23]Ошибка в конструкторе - в 99,999% случаев - ошибка программиста, а не битой памяти. А ошибки аппаратного уровня - не прикладного программиста задача. Suum cuique. Вон, в OSI семь уровней, и каждый уровень своими делами занимается, в чужие дела не лезет. Так и битая память - проблема администратора, а не прикладной программы.
Ну представь, потратишь ты десять лет своей жизни, напишешь супер-защищенный текстовый редактор, который на каждый эксепшн будет стучать в бубен, пытаясь отловить гипотетическую ошибку памяти, и, самое коварное - исправлять эту ошибку. Почему коварное? Потому что администратор будет сидеть и думать: если битая память, то почему все программы сбоят, а вот этот текстовый редактор - не сбоит. Нет, все же, проблема не в памяти,- решит админ,- ведь, если бы проблема была в памяти, то сбоили бы все программы без исключения. Кому потом админ будет говорить "спасибо" за запутывание симптомов?
И вообще, неужели так плохо с памятью в королевстве датском, что остро встает вопрос и экономически оправдано написание программ, отлавливающих ошибки с памятью?
Германн (2011-02-26 00:56:00) [24]
> И вот у меня возник вопрос. А что если при работающей программе
> где то в середине кода условно в момент выполнения SomeObject
> := TSomeObject.Create; создающаяся переменная или объект
> попадают на битый байт или бит в ОЗУ? При этом либо глобальная
> программа подвисает, либо аварийно закрывается Windows без
> освобождения ресурсов...
> А кто нибудь пытался отлавливать ошибки на уровне железа?
>
Это просто нереально. И дело не столько в железе, сколько в том, что "проверять каждую машинную инструкцию на ошибки с памятью" просто нереально. А иначе такую ошибку не поймать.
Inovet (2011-02-26 00:52:00) [25]А если, электричество отключат, или в комп кофий зальётся?
ОЗУ может быть с контролем чётности или с коррекцией ошибок, чтобы завершить всё и поменять. А в программе это смысла не имеет, при предположительном сбое его невозможно разпознать, т.к. после него сама программа распознавания может работать неверно.
clickmaker (2011-02-26 00:26:00) [26]> возможно ли отловить ошибки в ОЗУ (физические)...
без низкоуровневого доступа к физ. памяти - нет. Потому как приложение работает с виртуальной
| |
Страницы: 