Linux программирование в примерах

15.5.2.5. Другие отладчики malloc

Две статьи Cal Ericson в Linux Journal описывают mtrace и dmalloc, а также большинство других перечисленных ниже инструментов. Эти статьи Memory Leak Detection in Embedded Systems, выпуск 101 [184] , сентябрь 2002 г., и Memory Leak Detection in C++, выпуск 110 [185] , июнь 2003 г. Обе статьи доступны на веб-сайте Linux Journal.

184

http://www.linuxjournal.com/article.php?sid=6059 — Примеч. автора.

185

http://www.linuxjournal.com/article.php?sid=6556 — Примеч. автора.

Другие инструменты сходны по природе с описанными ранее.

ccmalloc

Замещающая malloc библиотека, которая не нуждается в особой компиляции и может использоваться с С++. См. http://www.inf.ethz.ch/personal/biere/projects/ccmalloc.

malloc Марка Мораеса (Mark Moraes)

Старинная, но полнофункциональная библиотека замещения malloc, предоставляющая возможности профилирования, трассировки и отладки. Вы можете получить ее с ftp://ftp.cs.toronto.edu/pub/moraes/malloc-1.18.tar.gz.

mpatrol

Пакет с большими возможностями настройки для отладки памяти и тестирования. См http://www.cbmamiga.demon.со.uk/mpatrol.

memwatch

Пакет, требующий использования специального заголовочного файла и опций времени компилирования. См. http://www.linkdata.se/sourcecode.html.

njamd

«Не просто еще один отладчик malloc» (Not Just Another Malloc Debugger). Эта библиотека не требует специальной компоновки с приложением; вместо этого она использует LD_PRELOAD для замены стандартных процедур. См. http://sourceforge.net/projects/njamd.

yamd

Похож на Electric Fence, но со многими дополнительными опциями. См. http://www3.hmc.edu/~neldredge/yamd.

Почти все из этих пакетов используют для точной настройки своего поведения переменные окружения. В таблице 15.1 на основе статей из Linux Journal сделана сводка различных пакетов.

Таблица 15.1. Сводка особенностей инструментов памяти

Инструмент	ОС	Заголовочный файл	Модуль/ программа	Многопоточность
ccmalloc	Многотипная	Нет	Программа	Нет
dmalloc	Многотипная	Необязательно	Программа	Да
efence	Многотипная	Нет	Программа	Нет
memwatch	Многотипная	Да	Программа	Нет
Moraes	Многотипная	Необязательно	Программа	Нет
mpatrol	Многотипная	Нет	Программа	Да
mtrace	Linux (GLIBC)	Да	Модуль	Нет
njamd	Многотипная	Нет	Программа	Нет
valgrind	Linux (GLIBC)	Нет	Программа	Да
yamd	Linux, DJGPP	Нет	Программа	Нет

Как видно, для отладки проблем динамической памяти доступен ряд выборов. На системах GNU/Linux и BSD один или более из этих инструментов, возможно, уже установлены, что избавляет вас от хлопот по их загрузке и построению.

Полезно также использовать для своей программы несколько инструментов подряд. Например, mtrace для обнаружения не освобождаемой памяти, a Electric Fence для перехвата доступа к недействительной памяти.

15.5.3. Современная lint

В оригинальном С компилятор не мог проверить, соответствуют ли параметры, переданные в вызове функции, списку параметров в определении функции; прототипов не было. Это часто вело к неуловимым ошибкам, поскольку ошибочный вызов функции мог вызывать лишь частично ошибочные результаты, которые проходили незамеченными во время тестирования, или мог даже вообще не появиться во время тестирования. Например:

if (argc < 2)
 fprintf ("usage: %s [ options ] files\n", argv[0]);
 /* отсутствует stderr */

Если программа, содержащая этот фрагмент, никогда не вызывается с ошибочным числом аргументов, fprintf, в которой отсутствует первый аргумент FILE*, также никогда не вызывается.

Программа V7 lint была предназначена для решения таких проблем. Она делала два прохода через все файлы программы, сначала собирая сведения об аргументах функций, а затем сравнивая вызовы функций с собранной информацией. Особые файлы «библиотеки lint» предоставляли сведения о функциях стандартных библиотек, так что их также можно было проверить, lint проверяла также другие сомнительные конструкции.

С появлением в стандартном С прототипов необходимость в lint уменьшилась, но не исчезла совсем, поскольку C89 все еще допускает объявления функций в старом стиле.

extern int some_func; /* Список аргументов неизвестен */

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

Программа splint (Secure Programming Lint — Lint для безопасного программирования) [186] является современным обновлением lint. Она предусматривает слишком много опций и возможностей, чтобы перечислять их здесь, но ее стоит исследовать.

186

http://www.splint.org — Примеч. автора.

Следует знать об одной особенности подобных lint программ, которая заключается в том, что они выводят целый поток предупреждающих сообщений. Многие из сообщаемых предупреждений в действительности безвредны. В таких случаях инструменты допускают использование специальных комментариев, сообщающих. «Да, я знаю об этом, это не проблема», splint лучше всего работает, когда вы предоставляете в своем коде большое количество подобных примечаний.

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

15.6. Тестирование программ

Разработка программного обеспечения содержит элементы и искусства, и науки, это одна сторона того, что делает ее такой восхищающей и стимулирующей профессией. Данный раздел вводит в тему тестирования программного обеспечения, которая также включает в себя и искусство, и науку; таким образом, это несколько более общий и высокий уровень (читай: «на который можно махнуть рукой»), чем остальная часть данной главы.

Тестирование программ является неотъемлемой частью процесса разработки программного обеспечения. Весьма маловероятно, что программа заработает правильно на 100 процентов при первой компиляции. Программа не несет ответственности за свою правильность; за это отвечает автор программы. Одним из самых важных способов проверки того, что программа работает так, как предполагалось, является ее тестирование.

Один из способов классификации различных видов тестов следующий:

Тесты модулей (Unit tests)

Это тесты, которые вы пишете для каждого модуля или функционального компонента своей программы. В качестве части работы может потребоваться также создать окружение (scaffolding) — код, предназначенный для предоставления поддерживающего каркаса, чтобы запустить модуль в виде отдельной программы.

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