Текст книги "Linux программирование в примерах"
Автор книги: Арнольд Роббинс
Жанры:
Программирование
,сообщить о нарушении
Текущая страница: 52 (всего у книги 55 страниц)
Две статьи Cal Ericson в Linux Journal описывают mtrace и dmalloc, а также большинство других перечисленных ниже инструментов. Эти статьи Memory Leak Detection in Embedded Systems, выпуск 101[184]184
http://www.linuxjournal.com/article.php?sid=6059 – Примеч. автора.
[Закрыть], сентябрь 2002 г., и Memory Leak Detection in C++, выпуск 110[185]185
http://www.linuxjournal.com/article.php?sid=6556 – Примеч. автора.
[Закрыть], июнь 2003 г. Обе статьи доступны на веб-сайте Linux Journal.
Другие инструменты сходны по природе с описанными ранее.
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 для перехвата доступа к недействительной памяти.
lintВ оригинальном С компилятор не мог проверить, соответствуют ли параметры, переданные в вызове функции, списку параметров в определении функции; прототипов не было. Это часто вело к неуловимым ошибкам, поскольку ошибочный вызов функции мог вызывать лишь частично ошибочные результаты, которые проходили незамеченными во время тестирования, или мог даже вообще не появиться во время тестирования. Например:
if (argc < 2)
fprintf ("usage: %s [ options ] filesn", argv[0]);
/* отсутствует stderr */
Если программа, содержащая этот фрагмент, никогда не вызывается с ошибочным числом аргументов, fprintf(), в которой отсутствует первый аргумент FILE*, также никогда не вызывается.
Программа V7 lint была предназначена для решения таких проблем. Она делала два прохода через все файлы программы, сначала собирая сведения об аргументах функций, а затем сравнивая вызовы функций с собранной информацией. Особые файлы «библиотеки lint» предоставляли сведения о функциях стандартных библиотек, так что их также можно было проверить, lint проверяла также другие сомнительные конструкции.
С появлением в стандартном С прототипов необходимость в lint уменьшилась, но не исчезла совсем, поскольку C89 все еще допускает объявления функций в старом стиле.
extern int some_func(); /* Список аргументов неизвестен */
Вдобавок, многие другие аспекты программы можно проверять статически, т.е. путем анализа исходных текстов.
Программа splint (Secure Programming Lint – Lint для безопасного программирования)[186]186
http://www.splint.org – Примеч. автора.
[Закрыть] является современным обновлением lint. Она предусматривает слишком много опций и возможностей, чтобы перечислять их здесь, но ее стоит исследовать.
Следует знать об одной особенности подобных lint программ, которая заключается в том, что они выводят целый поток предупреждающих сообщений. Многие из сообщаемых предупреждений в действительности безвредны. В таких случаях инструменты допускают использование специальных комментариев, сообщающих. «Да, я знаю об этом, это не проблема», splint лучше всего работает, когда вы предоставляете в своем коде большое количество подобных примечаний.
splint является мощным, но сложным инструментом; выделение некоторого времени на изучение его использования, а затем частое его использование поможет сохранить ваш код ясным.
Разработка программного обеспечения содержит элементы и искусства, и науки, это одна сторона того, что делает ее такой восхищающей и стимулирующей профессией. Данный раздел вводит в тему тестирования программного обеспечения, которая также включает в себя и искусство, и науку; таким образом, это несколько более общий и высокий уровень (читай: «на который можно махнуть рукой»), чем остальная часть данной главы.
Тестирование программ является неотъемлемой частью процесса разработки программного обеспечения. Весьма маловероятно, что программа заработает правильно на 100 процентов при первой компиляции. Программа не несет ответственности за свою правильность; за это отвечает автор программы. Одним из самых важных способов проверки того, что программа работает так, как предполагалось, является ее тестирование.
Один из способов классификации различных видов тестов следующий:
Тесты модулей (Unit tests)
Это тесты, которые вы пишете для каждого модуля или функционального компонента своей программы. В качестве части работы может потребоваться также создать окружение (scaffolding) – код, предназначенный для предоставления поддерживающего каркаса, чтобы запустить модуль в виде отдельной программы.
Важно спроектировать тесты для каждого функционального компонента во время его разработки. Это помогает прояснить проектирование особенностей; знание того, как это тестировать, помогает определить, что следует и что не следует делать в первую очередь.
Комплексные тесты (Integration tests)
Это тесты, которые применяются, когда все функциональные компоненты были написаны, протестированы и отлажены по отдельности. Идея в том, что все затем помешается на свое место в каркасе и тестируется все в целом, чтобы убедиться, что взаимодействия между компонентами работают.
Возвратные тесты (Regression tests)
Неизбежно вы (или ваши пользователи!) обнаружат проблемы. Это могут быть действительные ошибки, или ограничения дизайна, или неизбежные отказы в «пограничных случаях». Когда вы смогли воспроизвести и исправить проблему, сохраните первоначальные условия отказа в качестве возвратного теста.
Возвратный тест позволяет вам убедиться, что при проведении изменений не была повторена старая проблема. (Это случается довольно легко.) Пропустив программу после проделанных изменений через набор тестов, вы можете быть (более) уверены, что все работает таким образом, как предполагалось.
Тестирование следует по возможности автоматизировать. Это особенно легко сделать для программ, не содержащих графического пользовательского интерфейса (GUI), написанных в стиле инструментов Linux/Unix: читающих стандартный ввод или указанные файлы и записывающих в стандартный вывод и стандартную ошибку. По меньшей мере, тестирование можно осуществить с помощью простых сценариев оболочки. Более сложное тестирование осуществляется обычно с помощью отдельного подкаталога test и программы make.
Тестирование программного обеспечения само по себе является отдельной областью, и мы не предполагаем отдавать ей здесь должное; скорее, наше намерение дать вам знание, что тестирование является неотъемлемой частью разработки и часто движущей силой для использования ваших навыков в отладке! Вот очень короткий резюмирующий список.
• Проектируйте тест вместе с функциональностью
• Тестируйте пограничные условия: убедитесь, что функция работает внутри и на действительных границах и что она корректно выдает ошибку за их пределами. (Например, функция sqrt() должна потерпеть неудачу с отрицательным аргументом).
• Используйте в своем коде операторы проверки (см. раздел 12.1 «Операторы проверки assert()») и проведите свои тесты с разрешенными операторами проверки.
• Создайте и используйте повторно тестовое окружение.
• Сохраняйте условия сбоев для возвратного тестирования
• Как можно больше автоматизируйте тестирование.
• Печатайте число потерпевших неудачу тестов, чтобы легко можно было определить успех или неудачу, а также степень неудачи.
• Используйте инструменты обзора кода, такие, как gcov, чтобы удостовериться, что ваш набор тестов охватывает весь ваш код.
• Тестируйте с самого начала и тестируйте часто.
• Изучите литературу по тестированию программного обеспечения, чтобы совершенствовать свою способность разрабатывать и тестировать программное обеспечение.
15.7. Правила отладкиОтладка не является «черной магией». Ее принципы и методики могут быть изучены и последовательно применены каждым. С этой целью мы рекомендуем книгу Debugging Дэвида Эганса (David J. Agans; ISBN: 0-8144-7168-4). У книги есть веб-сайт[187]187
http://www.debuggingrules.com – Примеч. автора.
[Закрыть], на котором обобщены правила и представлен плакат для загрузки, чтобы вы могли его распечатать и повесить на стену в своем офисе.
Чтобы завершить наше обсуждение, мы представляем следующий материал. Он был адаптирован Дэвидом Эгансом по разрешению из Debugging, Copyright © 2002 David J. Agans, опубликованной AMACOM[188]188
http://www.amacombooks.org – Примеч. автора.
[Закрыть], отделением American Management Association, New York. Мы благодарим его.
1. Поймите систему. Когда ничто не помогает, прочтите руководство. Вам необходимо узнать, что должна делать проблемная система и все ее части, если хотите выяснить, почему она не работает. Поэтому прочтите всю документацию, которую можете получить в свои руки (и в свой браузер).
Знание того, где находятся функциональные блоки и размещаются данные, и как они взаимодействуют, дает вам схему для изоляции ошибки. Конечно, вам нужно знать также соответствующую область (язык, операционную систему, приложение) и свои инструменты (компилятор, отладчик исходного кода).
2. Вызовите сбой. Для того, чтобы увидеть ошибку, вы должны быть способны постоянно воспроизводить сбой. Задокументируйте свои процедуры и начните с известного состояния, чтобы вы всегда могли снова вызвать сбой. Ищите ошибку в системе, которая дает сбой, не старайтесь имитировать проблему на другой системе. Не доверяйте статистике непостоянных проблем; они скорее скроют ошибку, чем проявят ее. Вместо этого постарайтесь сделать ее устойчивой, изменяя вводимые данные, начальные условия и координацию действий.
Если ошибка все еще непостоянна, вам придется сделать так, чтобы она выглядела постоянной. При каждом запуске фиксируйте в журнале каждый бит информации, какой только сможете; затем, когда есть успешные запуски и сбои, сравните их друг с другом. Если вы собрали достаточно данных, вы сможете нацелиться на проблему, как если бы смогли вызывать ошибку все время. Способность вызывать каждый раз ошибку означает также, что вы сможете сказать, когда вы ее исправили.
3. Прекратите думать и смотрите. Имеется больше способов появления ошибок, чем вы можете себе представить. Поэтому не представляйте, что могло бы случиться, смотрите на это – оснастите систему инструментарием, чтобы вы действительно смогли увидеть механизм ошибки. Используйте любой инструментарий, который можете – отладчики, printf(), assert(), анализаторы логики и даже светодиоды и звуковые сигнализаторы. Проверяйте достаточно глубоко, пока ошибка не станет очевидной для глаз, а не только для мозга.
Если вы все же догадались, используйте догадку, чтобы сфокусировать поиск – не старайтесь исправить, пока вы ее не увидите. Если вам приходится добавлять код инструментария, сделайте это, но убедитесь, что начинаете с той же самой базы кода, как на проблемной системе, и убедитесь, что ошибка все еще возникает при работе вашего добавленного кода. Часто добавление отладчика вызывает исчезновение ошибки (вот почему его называют отладчиком).
4. Разделяй и властвуй. Каждый это знает. Вы делаете последовательное приближение – начинаете с одного конца, перескакиваете полпути, смотрите, с какой стороны ошибка, затем перескакиваете оставшиеся полпути в направлении ошибки. Бинарный поиск, вы оказываетесь так за несколько прыжков. Трудной частью является определение того, прошли вы ошибку или нет. Одной из полезных уловок является помещение в систему известных, простых данных, так чтобы можно было легче узнать мусор. Начните также с плохого конца и работайте по направлению к хорошему: если вы начнете с хорошего конца, имеется слишком много хороших путей для исследования. Известные ошибки исправляйте сразу, поскольку иногда две ошибки взаимодействуют (хотя вы могли бы поклясться, что они не должны этого делать), и последовательное приближение не работает с двумя целевыми значениями.
5. Каждый раз изменяйте лишь что-то одно. Если вы стараетесь усовершенствовать модуль обработки потоков и одновременно переходите на следующую версию операционной системы, не имеет значения, видите ли вы улучшение, ухудшение или отсутствие изменений – у вас не будет мыслей по поводу того, каким был результат ваших отдельных изменений. Взаимодействие нескольких изменений может быть непредсказуемым и сбивающим с толку. Не делайте этого. Изменяйте за один раз только что-то одно, чтобы вы могли поручиться, что любое отличие, которые вы видите, возникло из-за этого изменения.
Если вы делаете изменение, а результата не видно, немедленно вернитесь обратно. Возможно, оно имело результат, который вы не увидели, и он может проявиться в сочетании с другими изменениями. Это относится к изменениям как в тестировании, так и в кодировании.
6. Сохраняйте контрольные журналы. Многое в эффективности приведенных выше правил зависит от сохранения хороших записей. Во всех отношениях тестирования и отладки записывайте, что вы делали, когда вы это делали, как вы это делали и что случилось в результате. По возможности делайте это в электронном виде, чтобы записи можно было послать по электронной почте и прикрепить к базе данных ошибок. Многие ключи можно найти в паттернах событий, которые были бы не замечены, если бы все они не записывались для просмотра и сравнения. Ключ может находиться также в деталях, о которых вы думали, что они неважны, поэтому запишите их все.
7. Проверьте подключение. У каждого есть история о какой-нибудь проблеме, оказавшейся в том, что «это не было подключено». Иногда что-то оказывается буквально не подключенным, но для программного обеспечения «не подключено» может означать отсутствующий драйвер или старую версию кода, о которой вы думали, что заменили ее. Или плохое оборудование, когда вы клянетесь, что это проблема программного обеспечения. В одной истории инженеры-программисты и электронщики показывали пальцами друг на друга, и никто не был прав: тестирующее устройство, которое они использовали, не соответствовало спецификации. Основной момент в том, что иногда вы ищете проблему внутри системы, тогда как на самом деле она вне системы, или лежит в основе системы, или в инициализации системы, или вы смотрите не на ту систему.
Не следует также непременно доверять своим инструментам. Производители инструментов также являются инженерами; у них есть ошибки, и вы можете оказаться тем, кто их обнаружит.
8. Оцените свежим взглядом. Есть три причины попросить помощи при отладке.
Первая причина в получении свежего взгляда – другие люди часто видят что-то лишь потому, что они не вовлечены в это так, как вы. Вторая причина заключается в получении экспертной оценки – они знают о системе больше, чем вы. Третья причина заключается в получении опыта – они видели это раньше.
Когда вы описываете ситуацию кому-либо, сообщите о симптомах, которые вы видели, а не о своих предположениях, почему это происходит так. Вы пришли к ним, потому что ваши предположения не ведут вас никуда – не тяните их в ту же колею, в которую попали сами.
9. Если вы не исправили это, это не исправлено. Так вы думаете, это исправлено? Испытайте. Раз вы могли заставить ошибку повторяться постоянно, создайте ту же самую ситуацию и убедитесь, что ошибки нет. Не думайте, что все исправлено лишь потому, что проблема была очевидной. Может, она не была такой очевидной. Может, ваше исправление не было сделано правильно. Может, ваше исправление даже не находится в новом выпуске! Проверьте! Заставьте ошибку исчезнуть.
Вы уверены, что именно ваш код исправил проблему? Или это произошло из-за изменения теста, или туда был внесен какой-то другой код? Когда вы видите, что ваше исправление работает, уберите его и заставьте ошибку появиться снова. Затем верните исправление на место и убедитесь, что ошибки нет. Этот шаг гарантирует, что именно ваше исправление решило проблему.
Дополнительные сведения о книге Debugging и плакат с правилами отладки можно найти для свободной загрузки по адресу http://www.debuggingrules.com.
Следующие книги отличные, с множеством сведений как в отношении тестирования, так и отладки. Все, кроме первой, относятся к программированию вообще. Их все стоит прочесть.
1. Debugging, David J. Agans. AMACOM, New York, New York. USA 2003. ISBN: 0-8144-7168-4.
Настоятельно рекомендуем эту книгу. У нее легкий стиль, удивительное звучание, чтение – одно удовольствие!
2. Programming Pearls, 2nd edition, by Jon Louis Bentley. Addison-Wesley, Reading, Massachusetts, USA, 2000, ISBN: 0-201-63788-0. См. также веб-сайт этой книги.[189]189
http://www.cs.bell-labs.com/cm/cs/pearls/ – Примеч. автора.
[Закрыть]
В главе 5 этой книги приведено хорошее обсуждение тестирования элементов и построения тестовой среды.
3. Literate Programming, by Donald E. Knuth. Center for the Study of Language and Information (CSLI), Stanford University, USA, 1992. ISBN: 0-9370-7380-6.
Эта восхитительная книга содержит ряд статей Дональда Кнута по грамотному программированию (literate programming) – методике программирования, которую он изобрел и использовал для создания ТеХ и Metafont. Особый интерес представляет статья, озаглавленная «Ошибки ТеХ», которая описывает, как он разрабатывал и отлаживал ТеХ, включая его журнал всех найденных и исправленных ошибок.
4. Writing Solid Code, by Steve Maguire. Microsoft Press, Redmond, Washington, USA, 1993. ISBN 1-55615-551-4.
5. Code Complete: A Practical Handbook of Software Construction, by Steve McConnell Microsoft Press, Redmond, Washington, USA, 1994. ISBN: 1-55615-484-4.
6. The Practice of Programming, by Brian W. Kernighan and Rob Pike. Addison-Wesley, Reading. Massachusetts, USA, 1999. ISBN: 0-201-61585-X.
15.9. Резюме• Отладка является важной частью разработки программного обеспечения. Для минимизации ошибок должны использоваться хорошие проектирование и практика разработки, но отладка всегда будет с нами.
• Программы должны компилироваться без оптимизации и с включенными идентификаторами отладки, чтобы упростить отладку под отладчиком. На многих системах компиляция с оптимизацией и компиляция с идентификаторами отладки несовместимы. Это не относится к GCC, вот почему разработчикам GNU/Linux нужно знать об этой проблеме.
• Отладчик GNU GDB является стандартом на системах GNU/Linux и может использоваться также почти на любой коммерческой системе Unix. (Также доступны и легко переносимы графические отладчики на основе GDB.) Контрольные точки, отслеживаемые точки и пошаговое исполнение с посредством next, step и cont предоставляют базовый контроль над программой при ее работе. GDB позволяет также проверять данные и вызывать функции внутри отлаживаемой программы.
• Имеется множество вещей, которые вы можете сделать при написании программы для ее упрощения, когда неизбежно придется ее отлаживать. Мы рассмотрели следующие темы:
• Отладочные макросы для вывода состояния.
• Избегание макросов с выражениями.
• Перестановку кода для облегчения пошагового выполнения.
• Написание вспомогательных функций для использования их из отладчика.
• Избегание объединений.
• Помещение отладочного кода времени исполнения в готовую версию программы и обеспечение различных способов включения вывода этого кода.
• Добавление фиктивных функций для упрощения установки контрольных точек.
• Для помощи при отладке помимо простых отладчиков общего назначения существует ряд инструментов и библиотек. Библиотека dbug предоставляет элегантный внутренний отладчик, который использует многие из описанных нами методик последовательным, связанным образом.
• Существует множество отладочных библиотек для динамической памяти, имеющие сходные свойства. Мы рассмотрели три из них (mtrace, Electric Fence и dmalloc) и предоставили ссылки на несколько других. Программа Valgrind идет еще дальше, обнаруживая проблемы, относящиеся к неинициализированной памяти, а не только к динамической памяти.
• splint является современной альтернативой многоуважаемой программе V7 lint. Она доступна по крайней мере на системе одного из поставщиков GNU/Linux и легко может быть загружена и построена из исходных кодов.
• Помимо инструментов отладки, неотъемлемой частью процесса разработки программного обеспечения является также тестирование программ. Ее следует понять, запланировать и управлять ею с самого начала любого проекта разработки программного обеспечения, даже индивидуального.
• Отладка является умением, которому можно научиться. Мы рекомендуем прочесть книгу Debugging Дэвида Дж. Эганса и научиться применять его правила.
