Статья:
Поиск потерянных блоков памяти с помощью ascLib

Автор(ы): Михайлов С.
Дата: 04.11.2002

Потери памяти возникают чаще всего из-за неосвобождения занятой памяти после завершения ее использования. Чаще всего это случается из-за небрежности
программиста. Есть разные способы поиска таких утечек. Один из них — с помощью библиотеки ascLib — описан в этой статье.

Авторы:
Михайлов С.

Аннотация:
Потери памяти возникают чаще всего из-за неосвобождения занятой памяти после завершения ее использования. Чаще всего это случается из-за небрежности
программиста. Есть разные способы поиска таких утечек. Один из них — с помощью библиотеки ascLib — описан в этой статье.

Бывают ошибки гораздо злее, такие, как разрушения памяти за пределами области и освобождение невалидного указателя. Недавно я впервые за 5 последних лет практики стлкнулся с ошибкой "третьего уровня". Конечно, до Dr. Joseph M. Newcomer мне далеко (http://www.rsdn.ru/article/default.asp?vcpp/survrls.xml

Автор(ы): Dr. Joseph M. Newcomer
Дата: 18.06.2001
Статья посвящена проблемам перехода с Debug-версии на Release-версию. Рассматриваются
типичные ошибки, которые могут не проявляться в отладочной версии, но проявляются в финальной.
Обсуждается вопрос "ошибок компилятора" и вопросы необходимости оптимизации и ее побочные эффекты.
В последней редакции добавлен раздел посвященный проблеме совместимости динамических библиотек.

), но фан был получен изрядный. В общем, при определенных, крайне редких обстоятельствах, портился указатель в стеке, который приводил к порче элемента массива _в_пределах_ выделенной области, что в результате приводило к порче одного байта, находящегося уже за пределами другой выделенной области. По "счастливой" случайности порча происходила по адресу на 1 байт мельшем начала валидной области. Никакие DCRT, ни NuMega, ни один из Bound-Checkers под Linux (приложение многоплатформенное) не помогали — ошибка тут-же "пряталась". Не говоря уж о том, что проявлялась она только в Release версии. К "счастью", под Linux ситуация воспроизводилась несколько лучше. Я потратил 2 дня на ловлю этой ошибки, написав свой bound-checker. При этом способы, аналогичные DCRT, не приводили к успеху — ошибка "скрывалась". Напомним, что классическим способом проверки "порчи" является выделение несколько большего участка, запись в начало и в конец неких данных, и проверка их при освобождении. Такой способ не сработал — шаг влево, шаг вправо при выделении памяти — ошибка "прячется". В конце концов помогло следующее.
В статической памяти резервируем массив структур, описываюших каждый выделенный блок (адрес, имя cpp-файла, номер строки и по 2 int'a — что идут непосредственно до блока и сразу после блока). При освобождении проверяем во-первых, валидность освобождаемого указателя, во-вторых, не возникла-ли порча. Очевидно, что подозрение на порчу может возникнуть и просто так — никто ведь не гарантирует, что байты, лежащие рядом с блоком не будут изменены самими аллокаторами. Такое явление и наблюдалось в Windows, в Linux все было "чисто". Однако, я очень скоро научился отличать настоящую порчу от мнимой, сопоставив поведение под Windows и под Linux. Только таким образом и был "взят след".

Приветствую.
А ascLib еще жива? Все линки на нее мертвы. Где ее раздобыть можно?

Здравствуйте, alexxxander, Вы писали:

A>Приветствую.
A>А ascLib еще жива? Все линки на нее мертвы. Где ее раздобыть можно?

Можно взять здесь — была ранее взята с сайта