© Александр Новичков,
Компьютер-пресс #2 2001

Cтатья была опубликована на сайте www.compress.ru

C развитием аппаратной базы компьютерных систем - увеличением тактовой частоты до запредельных уровней (переваливших за гигагерц), ускорением обработки изображений в реальном масштабе времени при помощи супермощных видеоадаптеров многие разработчики не считают нужным (или возможным) оптимизировать написанные ими программные продукты, перенося весь неоптимизированный код на быструю подсистему, быстрый процессор, “умный” компилятор. Результат подобного злоупотребления мы наблюдаем ежедневно во время запуска программ на собственных компьютерах, отмечая странную тенденцию: чем новее программа, тем больше требует ресурсов, и тем медленнее работает. Но и это еще не все! Многие программы по окончании работы не освобождают все занимаемые ресурсы, что приводит к достаточно неприятным последствиям. Странно, не правда ли? Казалось бы, технологии программирования должны совершенствоваться и идти в ногу с аппаратными новинками, качественно используя все предоставляемые ими возможности, однако на деле все обстоит гораздо хуже. В погоне за новыми цифрами версий на коробках продуктов разработчики не считают нужным (возможным) проводить детальную оптимизацию написанного кода, тщательно отслеживая все вызовы и подсчитывая занимаемую системную память, поскольку занятие это трудоемкое и длительное, а получаемый результат не всегда оправдывает надежды: времени потрачено много, сил - еще больше, а производительность конечного продукта повысилась в лучшем случае на 9%, а то и меньше. Согласитесь, ситуация для нашего времени достаточно типичная, причем типична она для всех софтверных компаний, вне зависимости от ранга, размера, и, что немаловажно, от географического расположения. Лозунг: “время – деньги”, применяемый всеми к месту и не к месту, в данной ситуации дает явный сбой! Получается количество версий – в ущерб качеству.

За примером далеко ходить не придется: у всех есть нерасторопные операционные системы и офисные пакеты, которые с каждой новой реализации повышают аппаратные требования, функционально оставаясь при этом, на уровне 95 года.

Неужели все так страшно и бесперспективно? И “да” и “нет”. Все крупные компании, связанные с написанием программного обеспечения, пытаются найти способы наиболее эффективного тестирования, не выходя при этом за рамки бюджета конкретной разработки. Но, к сожалению, то ли ищут не там, то ли применяют не то, поскольку оптимизированных продуктов на рынке не так много.

Разработка качественных продуктов в отведенные сроки– вот задача, на решения которой направлены все продукты компании Rational. В частности, для этапа разработки высококачественного кода, компания, посредством RUP (Rational Unified Process – методологии разработки), компанией рекомендуется использование инструментов тестирования: Quantify, Purify, PureCoverage

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

• Quantify – собирает полную статистику о количестве вызовов функций в тестируемой программе, позволяя тем самым узнавать временные характеристики отдельных частей приложения
• Pure Coverage – позволит быстро найти участки кода, пропущенные при тестировании
• Purify – отлавливает все ошибки, связанные с утечкой памяти а также некоторые Run-time ошибки

Начать описание возможностей продукта Rational Purify хочется перефразированием одного очень известного изречения: “с точностью до миллиБАЙТА”. И это не случайно, ведь именно на решение всех проблем, связанных с утечкой памяти и предназначен данный продукт.

Ни для кого не секрет, что многие приложения ведут себя “не слишком скромно”, замыкая во время работы все системные ресурсы без большой на то необходимости. Данной болезни подвержены в основном крупные программные пакеты, и возникает подобная ситуация по причине нежелания программистов доводить созданный код “до ума”, но чаще подобное происходит не из за лени, а из-за невнимательности. Это понятно - современные темпы разработки ПО в условиях жесточайшего прессинга со стороны конкурентов не позволяют уделять слишком много времени оптимизации кода, ведь для этого необходимы и высокая квалификация, и наличие достаточного количества проектного времени. Как правило квалификация есть, а вот времени и денег на детальное тестирование кода на наличие “глюков” и “багов” практически нет. И в большинстве случаев, идя на поводу у клиентов крупные компании выпускают сырой код и тут же принимаются “латать” его различными патчами…

Еще раз попробую повторить, что львиная доля всех ошибок приходится на неправильное распределение/использование памяти, а также несанкционированный доступ за границы собственного адресного пространства, для программистов на С/С++ дополнительная головная боль – это указатель – еще одна брешь в системе.

Так вот, как мне видится, имея в своем распоряжении надежный инструмент, который бы сам в процессе работы над проектом указывал бы на подобные ошибки, то разработчики начали бы его повсеместное внедрение, повысив надежность создаваемого ПО, поскольку, как известно, что проще ошибку не допустить, чем потом с гордостью исправлять.

В общих чертах работа Rational Purify сводится к детальному выводу статистики об использовании памяти приложением (список ошибок и примеры устранения во второй главке).

Получаемой статистики вполне достаточно для получения общей, а затем – и детальной информации обо всем, что имеет отношение к памяти: утечки, потерянные блоки, фиктивные ссылки.

Purify позволяет анализировать исполняемый модуль, содержащий отладочную информацию, либо работать на уровне исходников, но только в среде Visual Studio (C++, Basic, Java).

Работа программы начинается со сбора информации о загружаемых библиотеках. То есть программа отыскивает ошибки не только внутренние но и внешние, разумеется, нельзя исправить ошибку в системной DLL, но если она там есть, то наверняка, можно написать дополнительный код в своей процедуре, отказавшись от вызова “некачественной” функции из DLL.

Перво-наперво идет детальное инструментирование всех модулей. Инструментирование сводится к тому, что Purify вставляет свою отладочную информацию в тело программы и вызываемых библиотек (технология Object Code Insertion). Для эффективной работы все “пройденные” библиотеки хранятся в кеше, что позволяет сократить необходимое время не перезапуск исправленного приложения.

Давайте рассмотрим возможности Purify в плане совместной работы с Microsoft Visual C++.

Интеграция компонентов от Rational выражается в появлении новых инструментальных панелей на поверхности рабочего стола в Development Studio. Получив полный набор тестирующих и профилирующих средств, разработчик обращается к ним по мере необходимости, не покидая рабочего пространства, что позволяет сэкономить массу времени на различные вызовы сторонних программ.

Рисунок 1 показывает примерный вид инструментальных панелей в Visual Studio, появляющихся после инсталляции Purify, Quantify, PureCoverage.

А учитывая давнюю дружбу Rational и Microsoft, становится понятно, почему поддерживаются в полной мере только среды разработчиков от MS.

Собрав воедино всю перечисленную информацию, давайте попробуем на конкретном примере в Visual C++, создать приложение, внести в него ряд намеренных ошибок после чего, используя Purify попытаться отыскать их.

Опустим за скобки то, каким образом создаются проекты в Visual Studio и из чего они состоят – это не самоцель. Исходим из того, что читатель уже работал с данной средой, или хотя бы знаком с ней – это - во-первых.

Во-вторых, для чистоты эксперимента мы воспользуемся стандартным “Волшебником” из состава Visual Studio, сгенерировав, на его основе проект, в который внесем некоторый код, который будет неадекватно себя вести с памятью системы…

Итак, у меня получилось 32-разрядное приложение для Windows с именем “PROJECTOID”. На рисунке 2 изображен скриншот окна Workspace после создания проекта. Для демонстрации преимуществ Purify не нужно заводить в примере тонны сложных классов, запутывая и себя, и программу, и статью: ограничимся лишь простыми вызовами на распределение памяти.

Для более наглядного способа отлова ошибок допишем пару строк в стандартный обработчик “OnAppAbout”:

void All::OnAppAbout()
{ 
char *alex; //Наша строка №1 
alex=(char *)malloc(20000); //Наша строка №2 
CAboutDlg aboutDlg; 
aboutDlg.DoModal(); 
}  

Добавление интеллекта к функции OnAppAbout сделано намерено, поскольку во время работы можно воспользоваться данной функцией несколько раз подряд, активируя диалог “ABOUT” после игр с его вызовом. Теперь завершим приложение, посмотрим статистику по памяти и под конец найдем “виновного” в полученной утечке памяти. Из фрагмента видно, что указатель “alex” смотрит в сторону блока длиной в 20Кб, который выделяется функцией MALLOC. Еще можно заметить, что: 1) указатель нигде не используется, 2) Блок памяти не освобождается.

Запускаем программу по F5, предварительно активировав Purify (увеличительные стекла на инструментальной панели Purify. См. рис. 1). В запущенном приложении трижды запускаем диалог ABOUT из верхнего меню и закрываем приложение.

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

Рисунок 3 иллюстрирует вид окна со статистикой по памяти. При внимательном рассмотрении становится видна вся подноготная как нашего модуля, так и шапки, сгенерированной компилятором Microsoft в лице Visual C++. Purify насчитала 43 (!) предупреждения о неправильном (читай: неэффективном) использовании памяти, а из них только одно наше было преднамеренно введено в программу. Хотя, если говорить совсем честно и открыто, то не все ошибки являются ошибками! (см вторую главку)

Вновь обратимся к рисунку со статистикой, где в явном виде находится информация по ошибкам и по модулям, в которых эти ошибки были обнаружены. К приятной неожиданности можно отнести фразу “Memory leak of 60000”, указывающую на то, сколько фактических байтов памяти программа не вернула системе, по завершении своей работы. Эта черта разительно отличает подходы к тестированию программы Rational Purify от подобных продуктов конкурирующих компаний, которые высчитывают не фактические утечки (полученные в результате нескольких вызовов при реальной работе приложения, а количество невозвращенных блоков, то есть ограничиваются лишь анализом (на уровне исходных текстов) программы с выявлением вызовов функций аллокирования памяти без последующего освобождения. Из этого и следует полученное число 60000 – фактически не освобожденных блоков (3 по 20000). После добавления функции free(alex) в конец обработчика OnAppAbout и перекомпиляции тестируемого приложения, Purify не обнаруживает никаких ошибок памяти, что и являлось нашей целью.

Рисунок 4 отображает окно c ошибкой, в котором Purify, подсветила конкретный фрагмент текста листинга.

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

Из предыдущего материала нам известно, что Rational Purify направлена на поиск ошибок в программах написанных на Visual Studio. Мы также знаем, что продукт способен проанализировать эффективность кода программы, как с использованием исходных кодов, так и без них.

К достоинствам программы можно отнести не только вышесказанное! Purify способна работать (запускаться) на трех уровнях: из среды интеграции (Visual Studio), как отдельная программа и наконец из командной строки (если при инсталляции ей разрешили “прописаться” в путях). Любой разработчик, пишущий визуальные изощрения под “Окна”, может отказаться от интерфейса командной строки за ненадобностью. И совершенно напрасно! Как известно корни доброй половины продуктов Rational уходят своими корнями в разные UNIX системы, для которых командная строка - вещь святая, и графическими средствами незаменяемая. Соответственно, все особенности продуктов перекочевали под Windows… где и прижились… в лучшей или худшей степени.

Давайте обратим наше внимание именно на командную строку и попробуем разобраться как и для чего она нужна в повседневной разработке. Из материала прошлой статьи известно, что для своей работы средства тестирования Rational используют патентованную (читай: засекреченную) технологию под названием OCI – Object Code Insertion. Соответственно, суть метода тестирования состоит в том, что в исполняемый код записываются специальные инструкции Purify. Здесь хочется еще раз акцентировать внимание на том, что код вставляется не только в пользовательский модуль, но и во все внешние библиотеки, что дает разработчику уникальную возможность по отладке программ, предоставляя полную статистику по всем модулям. А это позволит вовремя заменить/переписать/переделать некорректную DLL, а не ждать пока она сведет на “нет” все усилия по вылавливанию внутренних ошибок. К вопросу о скорости работы: код вставляется относительно долго, зато создается директория с кешем – DLL со вставленным OCI. Так что, каждый новый запуск проходит быстрее предыдущего.

Процесс записи объектного кода в приложения на языке Purify называется “инструментированием”, соответственно подобная операция выполняется каждый раз перед исполнением написанного приложения. Если это касается совместной работы с пакетами из VS, то дело происходит так: сначала приложение компилируется (обычным способом, без вставки OCI), затем, после подачи команды “RUN” - запускается Purify и начинается процесс вставки кода. Только по его завершению, приложение начнет исполняться.

Из самого же Purify дело обстоит еще проще: необходимо просто выбрать нужный EXE’шник. Естественно, и в том и в другом случае приложению (при необходимости) можно передать аргументы командной строки и настроить фильтры сообщений (об этом чуть ниже).

Полное же управление над процессом инструментирования можно получить из командной строки. Здесь есть некоторые возможности, отсутствующие в версиях GUI.

Например:

• Инструментирование как самого файла приложения, так и его копии (последняя создается автоматически)
• Только вставка кода без запуска приложения
• Запись кеша в указанную директорию
• И многое другое… всего 38 ключей

Конечно же командная строка во многом дублирует функции графической оболочки, что делает не совсем очевидным применения именно данной возможности. Для решения следующего примера нам нужно воспользоваться командной строкой поскольку, тестируемое приложение является сервисом Windows NT, который, разумеется, нельзя исполнить как простое приложение. В этом случае как нельзя кстати приходится функция записи OCI без исполнения файла, что позволит внести в него весь объектный код, а затем прописать данный сервис в реестре. Соответственно при старте сервиса у вас появится возможность получения информации о работоспособности сервиса.

Рецепт тестирования выглядит следующим образом:

1. Правильно настроить системные пути таким образом, чтобы из них были видны все директории Purify (особенно кеш: \Program Files\Rational\Purify), иначе процесс не пойдет на исполнение.
2. Откомпилированный сервис нужно запустить Purify из командной строки следующим образом: purify /Run=no /Out=service_pure.exe service.exe. Как видно из параметров, Purify инструментирует файл service.exe, помещая его копию вместе с OCI в service_pure.exe. Все происходит без запуска.
3. В ключе реестра \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services необходимо поставить ссылку на кешированный файл (service_pure.exe)
4. Во вкладке сервисов активировать пункт Allow Service to Interact with Desktop, выбрать режим запуска "manual"

Помимо системных сервисов, Rational Purify способна работать совместно с:

• Компонентами Active X
• Дочерними процессами
• Совместно написанными программами (Visual С++ & Visual Basic)
• COM серверами (in-proc и out-proc)
• Internet Information Server

Продолжение статьи