› › Использование статического и динамического анализа для повышения качества продукции и эффективности разработки. Анализ унаследованного кода, когда исходный код утрачен: делать или не делать? Основные плюсы метода статической проверки кода

Использование статического и динамического анализа для повышения качества продукции и эффективности разработки. Анализ унаследованного кода, когда исходный код утрачен: делать или не делать? Основные плюсы метода статической проверки кода

Аннотация

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

Введение

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

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

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

Классификация уязвимостей защиты

Когда требование корректной работы программы на всех возможных входных данных нарушается, становится возможным появление так называемых уязвимостей защиты (security vulnerability). Уязвимости защиты могут приводить к тому, что одна программа может использоваться для преодоления ограничений защиты всей системы в целом.

Классификация уязвимостей защиты в зависимости от программных ошибок:

  1. Переполнение буфера (buffer overflow). Эта уязвимость возникает из-за отсутствия контроля за выходом за пределы массива в памяти во время выполнения программы. Когда слишком большой пакет данных переполняет буфер ограниченного размера, содержимое посторонних ячеек памяти перезаписывается, и происходит сбой и аварийный выход из программы. По месту расположения буфера в памяти процесса различают переполнения буфера в стеке (stack buffer overflow), куче (heap buffer overflow) и области статических данных (bss buffer overflow).
  2. Уязвимости (tainted input vulnerability). Уязвимости могут возникать в случаях, когда вводимые пользователем данные без достаточного контроля передаются интерпретатору некоторого внешнего языка (обычно это язык Unix shell или SQL). В этом случае пользователь может таким образом задать входные данные, что запущенный интерпретатор выполнит совсем не ту команду, которая предполагалась авторами уязвимой программы.
  3. Ошибки форматных строк (format string vulnerability). Данный тип уязвимостей защиты является подклассом уязвимости. Он возникает из-за недостаточного контроля параметров при использовании функций форматного ввода-вывода printf, fprintf, scanf, и т. д. стандартной библиотеки языка Си. Эти функции принимают в качестве одного из параметров символьную строку, задающую формат ввода или вывода последующих аргументов функции. Если пользователь сам может задать вид форматирования, то эта уязвимость может возникнуть в результате неудачного применения функций форматирования строк.
  4. Уязвимости как следствие ошибок синхронизации (race conditions). Проблемы, связанные с многозадачностью, приводят к ситуациям, называемым: программа, не рассчитанная на выполнение в многозадачной среде, может считать, что, например, используемые ею при работе файлы не может изменить другая программа. Как следствие, злоумышленник, вовремя подменяющий содержимое этих рабочих файлов, может навязать программе выполнение определенных действий.

Конечно, кроме перечисленных существуют и другие классы уязвимостей защиты.

Обзор существующих анализаторов

Для обнаружения уязвимостей защиты в программах применяют следующие инструментальные средства:

  • Динамические отладчики. Инструменты, которые позволяют производить отладку программы в процессе её исполнения.
  • Статические анализаторы (статические отладчики). Инструменты, которые используют информацию, накопленную в ходе статического анализа программы.

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

В данной статье предложен обзор нескольких существующих статических анализаторов. Рассмотрим подробнее каждый из них.

1. BOON

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

2. CQual

Инструмент анализа для обнаружения ошибок в Си-программах. Программа расширяет язык Си дополнительными определяемыми пользователем спецификаторами типа. Программист комментирует свою программу с соответствующими спецификаторами, и cqual проверяет ошибки. Неправильные аннотации указывают на потенциальные ошибки. Сqual может использоваться, чтобы обнаружить потенциальную уязвимость форматной строки.

3. MOPS

(MOdel checking Programs for Security) - инструмент для поиска уязвимостей в защите в программах на Си. Его назначение: динамическая корректировка, обеспечивающая соответствие программы на Си статической модели. MOPS использует модель аудита программного обеспечения, которая призвана помочь выяснить, соответствует ли программа набору правил, определенному для создания безопасных программ.

4. ITS4, RATS, PScan, Flawfinder

Для поиска ошибок переполнения буфера и ошибок форматных строк используют следующие статические анализаторы:

  1. . Простой инструмент, который статически просматривает исходный Си/Си++-код для обнаружения потенциальных уязвимостей защиты. Он отмечает вызовы потенциально опасных функций, таких, например, как strcpy/memcpy, и выполняет поверхностный семантический анализ, пытаясь оценить, насколько опасен такой код, а так же дает советы по его улучшению.
  2. . Утилита RATS (Rough Auditing Tool for Security) обрабатывает код, написанный на Си/Си++, а также может обработать еще и скрипты на Perl, PHP и Python. RATS просматривает исходный текст, находя потенциально опасные обращения к функциям. Цель этого инструмента - не окончательно найти ошибки, а обеспечить обоснованные выводы, опираясь на которые специалист сможет вручную выполнять проверку кода. RATS использует сочетание проверок надежности защиты от семантических проверок в ITS4 до глубокого семантического анализа в поисках дефектов, способных привести к переполнению буфера, полученных из MOPS.
  3. . Сканирует исходные тексты на Си в поисках потенциально некорректного использования функций, аналогичных printf, и выявляет уязвимые места в строках формата.
  4. . Как и RATS, это статический сканер исходных текстов программ, написанных на Си/Си++. Выполняет поиск функций, которые чаще всего используются некорректно, присваивает им коэффициенты риска (опираясь на такую информацию, как передаваемые параметры) и составляет список потенциально уязвимых мест, упорядочивая их по степени риска.

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

5. Bunch

Средство анализа и визуализации программ на Си, которое строит граф зависимостей, помогающий аудитору разобраться в модульной структуре программы.

6. UNO

Простой анализатор исходного кода. Он был разработан для нахождения таких ошибок, как неинициализированные переменные, нулевые указатели и выход за пределы массива. UNO позволяет выполнять несложный анализ потока управления и потоков данных, осуществлять как внутри- так и межпроцедурный анализ, специфицировать свойства пользователя. Но данный инструмент не доработан для анализа реальных приложений, не поддерживает многие стандартные библиотеки и на данном этапе разработки не позволяет анализировать сколь-нибудь серьёзные программы.

7. FlexeLint (PC-Lint)

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

В конце работы выдаются сообщения нескольких основных типов:

  • Возможен нулевой указатель;
  • Проблемы с выделением памяти (например, нет free() после malloc());
  • Проблемный поток управления (например, недостижимый код);
  • Возможно переполнение буфера, арифметическое переполнение;
  • Предупреждения о плохом и потенциально опасном стиле кода.

8. Viva64

Инструмент , который помогает специалисту отслеживать в исходном коде Си/Си++-программ потенциально опасные фрагменты, связанные с переходом от 32-битных систем к 64-битным. Viva64 встраивается в среду Microsoft Visual Studio 2005/2008, что способствует удобной работе с этим инструментом. Анализатор помогает писать корректный и оптимизированный код для 64-битных систем.

9. Parasoft C++ Test

Специализированный инструмент для Windows, позволяющий автоматизировать анализ качества кода Си++. Пакет C++Test анализирует проект и генерирует код, предназначенный для проверки содержащихся в проекте компонентов. Пакет C++Test делает очень важную работу по анализу классов C++. После того как проект загружен, необходимо настроить методы тестирования. Программное обеспечение изучает каждый аргумент метода и возвращает типы соответствующих значений. Для данных простых типов подставляются значения аргументов по умолчанию; можно определить тестовые данные для определенных пользователем типов и классов. Можно переопределить аргументы C++Test, используемые по умолчанию, и выдать значения, полученные в результате тестирования. Особого внимания заслуживает способность C++Test тестировать незавершенный код. Программное обеспечение генерирует код-заглушку для любого метода и функции, которые еще не существуют. Поддерживается имитация внешних устройств и входных данных, задаваемых пользователем. И та и другая функции допускают возможность повторного тестирования. После определения тестовых параметров для всех методов пакет C++Test готов к запуску исполняемого кода. Пакет генерирует тестовый код, вызывая для его подготовки компилятор Visual C++. Возможно формирование тестов на уровне метода, класса, файла и проекта.

10. Coverity

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

11. KlocWork K7

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

12. Frama-C

Открытый, интегрированный набор инструментов для анализа исходного кода на языке Си. Набор включает ACSL (ANSI/ISO C Specification Language) - специальный язык, позволяющий подробно описывать спецификации функций Си, например, указать диапазон допустимых входных значений функции и диапазон нормальных выходных значений.

Этот инструментарий помогает производить такие действия:

  • Осуществлять формальную проверку кода;
  • Искать потенциальные ошибки исполнения;
  • Произвести аудит или рецензирование кода;
  • Проводить реверс-инжиниринг кода для улучшения понимания структуры;
  • Генерировать формальную документацию.

13. CodeSurfer

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

  • Анализ указателей;
  • Различные анализы потока данных (использование и определение переменных, зависимость данных, построение графа вызовов);
  • Скриптовый язык.

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

14. FxCop

Предоставляет средства автоматической проверки.NET-сборок на предмет соответствия правилам Microsoft .NET Framework Design Guidelines. Откомпилированный код проверяется с помощью механизмов рефлексии, парсинга MSIL и анализа графа вызовов. В результате FxCop способен обнаружить более 200 недочетов (или ошибок) в следующих областях:

  • Архитектура библиотеки;
  • Локализация;
  • Правила именования;
  • Производительность;
  • Безопасность.

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

15. JavaChecker

Это статический анализатор Java програм, основанный на технологии TermWare.

Это средство позволяет выявлять дефекты кода, такие как:

  • небрежная обработка исключений (пустые catch-блоки, генерирование исключений общего вида и.т.п.);
  • сокрытие имен (например, когда имя члена класса совпадает с именем формального параметра метода);
  • нарушения стиля (вы можете задавать стиль программирования с помощью набора регулярных выражений);
  • нарушения стандартных контрактов использования (например, когда переопределен метод equals, но не hashCode);
  • нарушения синхронизации (например, когда доступ к синхронизированной переменной находится вне synchronized блока).

Набором проверок можно управлять, используя управляющие комментарии.

Вызов JavaChecker можно осуществлять из ANT скрипта.

16. Simian

Анализатор подобия, который ищет повторяющийся синтаксис в нескольких файлах одновременно. Программа понимает синтаксис различных языков программирования, включая C#, T-SQL, JavaScript и Visual BasicR, а также может искать повторяющиеся фрагменты в текстовых файлах. Множество возможностей настройки позволяет точно настраивать правила поиска дублирующегося кода. Например, параметр порога (threshold) определяет, какое количество повторяющихся строк кода считать дубликатом.

Simian - это небольшой инструмент, разработанный для эффективного поиска повторений кода. У него отсутствует графический интерфейс, но его можно запустить из командной строки или обратиться к нему программно. Результаты выводятся в текстовом виде и могут быть представлены в одном из встроенных форматов (например, XML). Хотя скудный интерфейс и ограниченные возможности вывода результатов Simian требуют некоторого обучения, он помогает сохранить целостность и эффективность продукта. Simian подходит для поиска повторяющегося кода как в больших, так и в маленьких проектах.

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

Вывод

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


Статический анализ кода это процесс выявления ошибок и недочетов в исходном коде программ. Статический анализ можно рассматривать как автоматизированный процесс обзора кода. Остановимся на обзоре кода чуть подробнее.

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" (Steve McConnell, "Code Complete") .

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

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

Задачи, решаемые программами статического анализа кода можно разделить на 3 категории:

  • Выявление ошибок в программах. Подробнее про это будет рассказано ниже.
  • Рекомендации по оформлению кода. Некоторые статические анализаторы позволяют проверять, соответствует ли исходный код, принятому в компании стандарту оформления кода. Имеется в виду контроль количества отступов в различных конструкциях, использование пробелов/символов табуляции и так далее.
  • Подсчет метрик . Метрика программного обеспечения - это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. Существует разнообразных метрик, которые можно подсчитать, используя те ли иные инструменты.

Другие преимущества статического анализа кода:

  • Полное покрытие кода. Статические анализаторы проверяют даже те фрагменты кода, которые получают управление крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
  • Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки . Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье " ".
  • Можно легко и быстро обнаруживать опечатки и . Как правило, нахождение этих ошибок другими способами является кране неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида "strcmp(A, A)". Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Недостатки статического анализа кода

  • Статический анализ, как правило, слаб в диагностике утечек памяти и параллельных ошибок. Чтобы выявлять подобные ошибки, фактически необходимо виртуально выполнить часть программы. Это крайне сложно реализовать. Также подобные алгоритмы требуют очень много памяти и процессорного времени. Как правило, статические анализаторы ограничиваются диагностикой простых случаев. Более эффективным способом выявления утечек памяти и параллельных ошибок является использование инструментов динамического анализа.
  • Программа статического анализа предупреждает о подозрительных местах. Это значит, что на самом деле код, может быть совершенно корректен. Это называется ложно-позитивными срабатываниями. Понять, указывает анализатор на ошибку или выдал ложное срабатывание, может только программист. Необходимость просматривать ложные срабатывания отнимает рабочее время и ослабляет внимание к тем участкам кода, где в действительности содержатся ошибки.

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.

При статическом анализе (static analysis) можно обнаружить много разнообразных дефектов и слабых мест исходного кода даже до того, как код будет готов для запуска. С другой стороны, динамический анализ (runtime analysis), или анализ во время выполнения, происходит на работающем программном обеспечении и обнаруживает проблемы по мере их возникновения, обычно используя сложные инструментальные средства. Кто-то может возразить, что одна форма анализа предваряет другую, но разработчики могут комбинировать оба способа для ускорения процессов разработки и тестирования, а также для повышения качества выдаваемого продукта.

В данной статье вначале рассматривается метод статического анализа. С его помощью можно предотвратить проблемы до их проникновения в состав основного программного кода и гарантировать, что новый код соответствует стандарту. Используя разные техники анализа, например, проверку абстрактного синтаксического дерева (abstract syntax tree, AST) и анализ кодовых путей, инструменты статического анализа могут выявить скрытые уязвимости, логические ошибки, дефекты реализации и другие проблемы. Это может происходить как на этапе разработки на каждом рабочем месте, так и во время компоновки системы. Далее в статье исследуется метод динамического анализа, который можно использовать на этапе разработки модулей и системной интеграции и который позволяет выявить проблемы, пропущенные при статическом анализе. При динамическом анализе не только обнаруживаются ошибки, связанные с указателями и другими некорректностями, но и есть возможность также оптимизировать использование циклов ЦПУ, ОЗУ, флеш-памяти и других ресурсов.

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

Объединяя лучшее из двух миров

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

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

Разработчики могут использовать инструменты статического анализа в любое время на этапе разработки, даже когда написаны лишь фрагменты проекта. Однако чем более завершенным является код, тем лучше. При статическом анализе могут просматриваться все потенциальные пути исполнения кода – при обычном тестировании такое происходит редко, если только в проекте не требуется обеспечения 100%-го покрытия кода. Например, при статическом анализе можно обнаружить программные ошибки, связанные с краевыми условиями или ошибками путей, не тестируемыми во время разработки.

Поскольку во время статического анализа делается попытка предсказать поведение программы, основанное на модели исходного кода, то иногда обнаруживается "ошибка", которой фактически не существует – это так называемое "ложное срабатывание" (false positive). Многие современные средства статического анализа реализуют улучшенную технику, чтобы избежать подобной проблемы и выполнить исключительно точный анализ.

Статический анализ: аргументы "за" Статический анализ: аргументы "против"
Используется уже на ранних этапах жизненного цикла программного обеспечения, прежде чем код готов для исполнения и до начала тестирования.

Могут анализироваться существующие базы кодов, которые уже прошли тестирование.

Средства могут быть интегрированы в среду разработки в качестве части компонента, используемого при "ночных сборках" (nightly builds) и как часть инструментального набора рабочего места разработчика.

Низкие стоимостные затраты: нет необходимости создавать тестовые программы или фиктивные модули (stubs); разработчики могут запускать свои собственные виды анализа.

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

Ненулевая вероятность "ложного срабатывания".

Таблица 1 - Аргументы "за" и "против" статического анализа.

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

Во многих случаях в инструменте динамического анализа производится модификация исходного или бинарного кода приложения, чтобы установить ловушки, или процедуры-перехватчики (hooks), для проведения инструментальных измерений. C помощью этих ловушек можно обнаружить программные ошибки на этапе выполнения, проанализировать использование памяти, покрытие кода и проверить другие условия. Инструменты динамического анализа могут генерировать точную информацию о состоянии стека, что позволяет отладчикам отыскать причину ошибки. Поэтому, когда инструменты динамического анализа находят ошибку, то, скорее всего, это настоящая ошибка, которую программист может быстро идентифицировать и исправить. Следует заметить, что для создания ошибочной ситуации на этапе выполнения должны существовать точно необходимые условия, при которых проявляется программная ошибка. Соответственно, разработчики должны создать некоторый контрольный пример для реализации конкретного сценария.

Динамический анализ: аргументы "за" Динамический анализ: аргументы "против"
Редко возникают "ложные срабатывания" – высокая продуктивность по нахождению ошибок

Для отслеживания причины ошибки может быть произведена полная трассировка стека и среды исполнения.

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

 Происходит вмешательство в поведение системы в реальном времени; степень вмешательства зависит количества используемых инструментальных вставок. Это не всегда приводит к возникновению проблем, но об этом нужно помнить при работе с критическим ко времени кодом.

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

Таблица 2 - Аргументы "за" и "против" динамического анализа.

Раннее обнаружение ошибок для уменьшения затрат на разработку

Чем раньше обнаруживается программная ошибка, тем быстрее и дешевле ее можно исправить. Поэтому инструменты статического и динамического анализа представляют реальную ценность, обеспечивая поиск ошибок на ранних этапах жизненного цикла программного обеспечения. Различные исследования промышленных продуктов показывают, что коррекция проблемы на этапе тестирования системы (для подтверждения качества ее работы, QA) или уже после поставки системы оказывается на несколько порядков более дорогостоящей, чем устранение тех же проблем на этапе разработки программного обеспечения. Многие организации имеют свои оценочные показатели относительно затрат на устранение дефектов. На рис. 1 приведены данные по обсуждаемой проблеме, взятые из часто цитируемой книги Каперса Джонса (Capers Jones) "Applied Software Measurement" ("Прикладные измерения программного обеспечения") .

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

Статический анализ

Статический анализ используется в практике программных разработок почти столь же долго, как существует сама разработка программного обеспечения. В своем первоначальном виде анализ сводился к контролю соответствия стандартам стиля программирования (lint). Разработчики пользовались этим непосредственно на своем рабочем месте. Когда дело доходило до обнаружения программных ошибок, то в ранних инструментах статического анализа основное внимание обращалось на то, что лежит на поверхности: стиль программирования и часто возникающие синтаксические ошибки. Например, даже самые простейшие инструменты статического анализа смогут обнаружить ошибку такого рода:

Int foo(int x, int* ptr) { if(x & 1); { *ptr = x; return; } ... }

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

Ранние инструменты анализа обращали внимание, главным образом, на синтаксические ошибки. Поэтому, хотя при этом и можно было обнаружить серьезные ошибки, все же большинство обнаруживаемых проблем оказывались относительно тривиальными. Кроме того, для инструментов предоставлялся достаточно небольшой кодовый контекст, чтобы можно было ожидать точных результатов. Это происходило потому, что работа проводилась в течение типичного цикла компиляции/компоновки при разработке, а то, что делал разработчик, представляло собой лишь маленькую частицу кода большой программной системы. Такой недостаток приводил к тому, что в инструменты анализа закладывались оценки и гипотезы относительно того, что может происходить за пределами "песочницы" разработчика. А это, в свою очередь, приводило к генерации повышенного объема отчетов с "ложными срабатываниями".

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

Для выполнения таких изощренных форм анализа в инструментах статического анализа имеют дело с двумя основными типами проверок кода:

  • Проверка абстрактного синтаксического дерева - для проверки базового синтаксиса и структуры кода.
  • Анализ кодовых путей - для выполнения более полного анализа, который зависит от понимания состояния программных объектов данных в конкретной точке на пути исполнения кода.

Абстрактные синтаксические деревья

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

Очень просто построить программу контроля, которая проверяет соблюдение стандартов относительно соглашения по присваиванию имен и ограничений по функциональным вызовам, например, контроль небезопасных библиотек. Цель выполнения проверок по AST обычно состоит в получении каких-либо логических выводов на основании кода как такового без использования знаний о поведении кода в процессе исполнения.

Многие инструменты предлагают проверки на основе AST для множества языков, включая инструменты с открытым исходным кодом, например, PMD для Java. Некоторые инструменты используют грамматику Х-путей или производную от Х-путей грамматику, чтобы определять условия, которые представляют интерес для программ контроля. Другие инструменты предоставляют расширенные механизмы, дающие возможность пользователям создавать свои собственные программы проверки на основе AST. Такой тип проверки относительно просто проводить, и многие организации создают новые программы проверки такого типа, чтобы проверить соблюдение корпоративных стандартов написания кода или рекомендованных по отрасли лучших методов организации работ.

Анализ кодовых путей

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

If(x & 1) ptr = NULL; *ptr = 1;

Поверхностное рассмотрение фрагмента приводит к очевидному выводу, что переменная ptr может принимать значение NULL, если переменная x – нечетна, и это условие при разыменовании неизбежно приведет к обращению к нулевой странице. Тем не менее, при создании программы проверки на основе AST найти такую программную ошибку весьма проблематично. Рассмотрим дерево AST (в упрощенном виде для ясности), которое было бы создано для приведенного выше фрагмента кода:

Statement Block If-statement Check-Expression Binary-operator & x 1 True-Branch Expression-statement Assignment-operator = ptr 0 Expression-statement Assignment-operator = Dereference-pointer - ptr 1 В подобных случаях никакой поиск по дереву или простое перечисление узлов не смогут обнаружить в разумно обобщенной форме предпринимаемую попытку (по меньшей мере, иногда недопустимую) разыменования указателя ptr. Соответственно, инструмент анализа не может просто проводить поиск по синтаксической модели. Необходимо также анализировать жизненный цикл объектов данных по мере их появления и использования внутри управляющей логики в процессе исполнения.

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

  • Не был ли вновь созданный объект освобожден прежде, чем из области видимости были удалены все обращающиеся к нему ссылки?
  • Проводилась ли для некоторого объекта данных проверка разрешенного диапазона значений, прежде чем объект передается функции ОС?
  • Проверялась ли строка символов на наличие в ней специальных символов перед передачей этой строки в качестве SQL-запроса?
  • Не приведет ли операция копирования к переполнению буфера?
  • Безопасно ли в данное время вызывать эту функцию?

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

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

Последовательность действий при выполнении статического анализа

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

Уникальный в своем роде продукт Klocwork Insight позволяет проводить анализ кода, создаваемого на рабочем месте конкретного разработчика, при этом избегать проблем, связанных с неточностью диагностики, что обычно свойственно инструментам подобного рода. Компания Klocwork предоставляет возможность проведения связного анализа кода на рабочем месте (Connected Desktop Analysis), когда выполняется анализ кода разработчика с учетом понимания всех системных зависимостей. Это приводит к проведению локального анализа, который является в такой же мере точным и мощным, как и централизованный системный анализ, но все это выполняется до полной сборки кода.

С точки зрения перспектив относительно последовательности действий при анализе, данная способность позволяет разработчику провести точный и высококачественный статический анализ на самом раннем этапе жизненного цикла разработки. Инструмент Klockwork Insight выдает в интегрированную среду разработчика (IDE) или в командную строку сообщения по всем проблемам по мере написания разработчиком кода и периодического выполнения им операций компиляции/компоновки. Выдача таких сообщений и отчетов происходит до выполнения динамического анализа и до того, как все разработчики сведут свои коды воедино.

Рис. 2 - Последовательность выполнения статического анализа.

Технология динамического анализа

Для обнаружения программных ошибок в инструментах динамического анализа часто производится вставка небольших фрагментов кода либо непосредственно в исходный текст программы (вставка в исходный код), либо в исполняемый код (вставка в объектный код). В таких кодовых сегментах выполняется "санитарная проверка" состояния программы и выдается отчет об ошибках, если обнаруживается что-то некорректное или неработоспособное. В таких инструментах могут быть задействованы и другие функции, например, отслеживание распределения памяти и ее использования во времени.

Технология динамического анализа включает в себя:

  • Размещение вставок в исходный код на этапе препроцессорной обработки – в исходный текст приложения до начала компиляции вставляется специальный фрагмент кода для обнаружения ошибок. При таком подходе не требуется детального знания среды исполнения, в результате чего такой метод пользуется популярностью среди инструментов тестирования и анализа встраиваемых систем. В качестве примера такого инструмента можно привести продукт IBM Rational Test RealTime.
  • Размещение вставок в объектный код – для такого инструмента динамического анализа необходимо обладать достаточными знаниями относительно среды исполнения, чтобы иметь возможность вставлять код непосредственно в исполняемые файлы и библиотеки. При этом подходе не нужно иметь доступа к исходному тексту программы или делать перекомпоновку приложения. В качестве примера такого инструмента можно привести продукт IBM Rational Purify.
  • Вставка кода во время компиляции – разработчик использует специальные ключи (опции) компилятора для внедрения в исходный код. Используется способность компилятора обнаруживать ошибки. Например, в компиляторе GNU C/C++ 4.x используется технология Mudflap для выявления проблем, касающихся операций с указателями.
  • Специализированные библиотеки этапа исполнения – для обнаружения ошибок в передаваемых параметрах разработчик использует отладочные версии системных библиотек. Дурной славой пользуются функции типа strcpy() из-за возможности появления нулевых или ошибочных указателей во время исполнения. При использовании отладочных версий библиотек такие "плохие" параметры обнаруживаются. Данная технология не требует перекомпоновки приложения и в меньшей степени влияет на производительность, чем полноценное использование вставок в исходный/объектный код. Данная технология используется в инструменте анализа ОЗУ в QNX® Momentics® IDE.

В данной статье мы рассмотрим технологии, используемые в инструментах разработчика QNX Momentics, особенно обращая внимание на GCC Mudflap и специализированные библиотеки этапа исполнения.

GNU C/C++ Mudflap: внедрение в исходный код на этапе компиляции

В инструментальном средстве Mudflap, присутствующем в версии 4.х компилятора GNU C/C++ (GCC), используется внедрение в исходный код во время компиляции. При этом во время исполнения происходит проверка конструкций, потенциально несущих в себе возможность появления ошибок. Основное внимание в средстве Mudflap обращается на операции с указателями, поскольку они являются источником многих ошибок на этапе выполнения для программ, написанных на языках C и C++.

С подключением средства Mudflap в работе компилятора GCC появляется еще один проход, когда вставляется проверочный код для операций с указателями. Вставляемый код обычно выполняет проверку на достоверность значений передаваемых указателей. Неправильные значения указателей приведут к выдаче компилятором GCC сообщений на стандартное устройство выдачи ошибок консоли (stderr). Средство Mudflap для контроля за указателями не просто проверяет указатели на нулевое значение: в его базе данных хранятся адреса памяти для действительных объектов и свойства объектов, например, местоположение в исходном коде, метка даты/времени, обратная трассировка стека при выделении и освобождении памяти. Такая база данных позволяет быстро получить необходимые данные при анализе операций доступа к памяти в исходном коде программы.

В библиотечных функциях, подобных strcpy(), не выполняется проверка передаваемых параметров. Такие функции не проверяются и средством Mudflap. Тем не менее, в Mudflap можно создать символьную оболочку (symbol wrapper) для статически подключаемых библиотек или вставку для динамических библиотек. При такой технологии между приложением и библиотекой создается дополнительный слой, что дает возможность провести проверку достоверности параметров и выдать сообщение о проявлении отклонений. В средстве Mudflap используется эвристический алгоритм, основанный на знании границ памяти, используемых приложением (динамическая память, стек, сегменты кода и данных и т.д.), чтобы определить правильность значений возвращаемых указателей.

Используя ключи командной строки компилятора GCC, разработчик может подключить возможности Mudflap для вставки кодовых фрагментов и управления поведением, например, управление нарушениями (границ, значений), проведение дополнительных проверок и настроек, подключение эвристических методов и самодиагностики. Например, комбинация ключей -fmudflap устанавливает конфигурацию Mudflap по умолчанию. Сообщения компилятора о выявленных средством Mudflap нарушениях выдаются на выходную консоль (stderr) или в командную строку. В подробном выводе предоставляется информация о нарушении и о задействованных при этом переменных, функциях, а также о местонахождении кода. Эта информация может автоматически импортироваться в среду IDE, где происходит ее визуализация, и выполняется трассировка стека. Пользуясь этими данными, разработчик может быстро перейти к соответствующему месту исходного кода программы.

На рис. 3 показан пример представления ошибки в среде IDE вместе с соответствующей информацией по обратной трассировке. Обратная трассировка работает как связующее звено с исходным кодом, что позволяет разработчику быстро диагностировать причину проблемы.

При использовании средства Mudflap может возрасти время на компоновку, и может уменьшиться производительность во время исполнения. Данные, представленные в статье “Mudflap: Pointer Use Checking for C/C++” ("Средство Mudflap: проверка использования указателей для языков C/C++”) говорят о том, что с подключением Mudflap время компоновки возрастает в 3…5 раз, а программа начинает работать медленнее в 1.25 … 5 раз. Совершенно ясно, что разработчики критических по времени исполнения приложений должны пользоваться эти средством с осторожностью. Тем не менее Mudflap является мощным средством для выявления подверженных ошибкам и потенциально фатальных кодовых конструкций. Компания QNX планирует использовать средство Mudflap в будущих версиях своих инструментов динамического анализа.

Рис. 3 - Использование информации обратной трассировки, отображаемой в среде QNX Momentics IDE для поиска исходного кода, приведшего к ошибке.

Отладочные версии библиотек этапа исполнения

Наряду с использованием специальных отладочных вставок в библиотеки этапа исполнения, которые приводят к значительным дополнительным расходам памяти и времени на этапах компоновки и исполнения, разработчики могут использовать предварительно подготовленные (pre-instrumented) библиотеки этапа исполнения. В таких библиотеках вокруг функциональных вызовов добавляется определенный код, цель которого состоит в проверке достоверности входных параметров. Например, рассмотрим старую знакомую – функцию копирования строк:

strcpy(a,b);

В ней участвуют два параметра, оба являющиеся указателями на тип char : один для исходной строки (b ), а другой для строки-результата (a ). Несмотря на такую простоту, эта функция может являться источником множества ошибок:

  • если значение указателя a равно нулю или является недействительным, то копирование по этому адресу назначения приведет к ошибке запрета доступа к памяти;
  • если значение указателя b равно нулю или является недействительным, то чтение информации с этого адреса приведет к ошибке запрета доступа к памяти;
  • если в конце строки b пропущен завершающий строку символ "0", то в строку назначения будет скопировано большее число символов, чем ожидается;
  • если размер строки b больше размера памяти, выделенного под строку a , то по указанному адресу будет записано больше байт, чем предполагалось (типичный сценарий переполнения буфера).

В отладочной версии библиотеки производится проверка значений параметров ‘a ’ и ‘b ’. Проверяются также длины строк, чтобы убедиться в их совместимости. Если обнаруживается недействительный параметр, то выдается соответствующее аварийное сообщение. В среде QNX Momentics данные сообщения об ошибках импортируются из целевой системы и выводятся на экран. В среде QNX Momentics используется также технология слежениями за случаями выделения и освобождения памяти, что дает возможность выполнять глубокий анализ использования ОЗУ.

Отладочная версия библиотеки будет работать с любым приложением, в котором используются ее функции; не нужно вносить никаких дополнительных изменений в код. Более того, разработчик может добавить библиотеку во время запуска приложения. Тогда библиотека заменит соответствующие части полной стандартной библиотеки, устраняя необходимость использовать отладочную версию полной библиотеки. В среде QNX Momentics IDE разработчик может добавить такую библиотеку при запуске программы как элемент нормального интерактивного сеанса отладки. На рис. 4 показан пример того, как в среде QNX Momentics происходит обнаружение и выдача сообщений об ошибках работы с памятью.

В отладочных версиях библиотек предоставляется проверенный "неагрессивный" метод обнаружения ошибок при вызовах библиотечных функций. Такая технология идеальна для анализа ОЗУ и для других методов анализа, которые зависят от согласованных пар вызовов, например, malloc() и free(). Другими словами, данная технология может обнаруживать ошибки на этапе исполнения только для кодов с библиотечными вызовами. При этом не обнаруживаются многие типичные ошибки, такие как встроенный код разыменования ссылки (inline pointer dereferences) или некорректные арифметические операции с указателями. Обычно при отладке осуществляется контроль только некоторого подмножества системных вызовов. Подробнее с этим можно познакомиться в статье .

Рис. 4 - Анализ ОЗУ происходит путем расстановки ловушек в области вызовов API, связанных с обращением к памяти.

Последовательность действий при динамическом анализе

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

Как показано на рис. 5, динамический анализ не только позволяет обнаружить ошибки, но и помогает обратить внимание разработчика на подробности расходования памяти, циклов ЦПУ, дискового пространства и других ресурсов. Процесс анализа состоит из нескольких шагов, и хороший инструмент для динамического анализа предоставляет надежную поддержку каждого шага:

  1. Наблюдение – прежде всего, происходит захват ошибок среды выполнения, обнаружение мест утечки памяти и отображение всех результатов в среде IDE.
  2. Корректировка – далее разработчик имеет возможность провести трассировку каждой ошибки назад до нарушающей работу строки исходного текста. При хорошей интеграции в среду IDE каждая ошибка будет отображаться на экране. Разработчику нужно просто щелкнуть мышью на строке ошибки, и откроется фрагмент исходного кода со строкой, нарушающей работу. Во многих случаях разработчик может быстро устранить проблему, используя доступную трассировку стека и дополнительные инструменты работы с исходным кодом в среде IDE (средства просмотра вызовов функций, средства трассировки вызовов и т.д.).
  3. Профилирование – устранив обнаруженные ошибки и утечки памяти, разработчик может проанализировать использование ресурсов во времени, включая пиковые ситуации, среднюю загрузку и избыточное расходование ресурсов. В идеальном случае инструмент анализа выдаст визуальное представление долговременного использования ресурсов, позволяя немедленно идентифицировать всплески в распределении памяти и иные аномалии.
  4. Оптимизация – используя информацию этапа профилирования, разработчик может теперь провести "тонкий" анализ использования ресурсов программой. Среди прочего, подобная оптимизация может минимизировать случаи пикового использования ресурсов и их избыточное расходование, включая работу с ОЗУ и использование времени ЦПУ.

Рис. 5 - Типовая последовательность действий при динамическом анализе

Комбинирование последовательности действий различных видов анализа в среде разработки

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

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

Вот какой можно предложить пример совместного использования двух видов инструментов:

  1. В начале рабочего дня разработчик просматривает отчет о результатах ночной компоновки. В данный отчет включаются как собственно ошибки компоновки, так и результаты статического анализа, проведенного во время компоновки.
  2. В отчете по статическому анализу приводятся обнаруженные дефекты наряду с информацией, которая поможет в их устранении, в том числе ссылки на исходный код. Используя среду IDE, разработчик может пометить каждую ситуацию либо как действительно найденную ошибку, либо как "ложное срабатывание". После этого производится исправление фактически присутствующих ошибок.
  3. Разработчик локально, внутри среды IDE, сохраняет внесенные изменения вместе с любыми новыми фрагментами кода. Разработчик не передает эти изменения обратно в систему управления исходными текстами до тех пор, пока изменения не будут проанализированы и протестированы.
  4. Разработчик анализирует и корректирует новый код, используя инструмент статического анализа на локальном рабочем месте. Для того чтобы быть уверенным в качественном обнаружении ошибок и отсутствии "ложных срабатываний", в анализе используется расширенная информация на уровне системы. Эта информация берется из данных выполненного в ночное время процесса компоновки/анализа.
  5. После анализа и "чистки" любого нового кода разработчик встраивает код в локальный тестовый образ или исполняемый файл.
  6. Используя инструменты динамического анализа, разработчик запускает тесты для проверки внесенных изменений.
  7. С помощью среды IDE разработчик может быстро выявить и исправить ошибки, о которых сообщается через инструменты динамического анализа. Код считается окончательным и готовым к использованию, когда он прошел через статический анализ, блочное тестирование и динамический анализ.
  8. Разработчик передает изменения в систему управления исходными текстами; после этого измененный код участвует в процессе последующей ночной компоновки.

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

Роль архитектуры ОСРВ

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

Например, в микроядерной ОСРВ типа QNX Neutrino все приложения, драйверы устройств, файловые системы и сетевые стеки располагаются за пределами ядра в отдельных адресных пространствах. В результате все они оказываются изолированными от ядра и друг от друга. Такой подход обеспечивает наивысшую степень локализации сбоев: отказ одного из компонентов не приводит к краху системы в целом. Более того, оказывается, что можно легко локализовать ошибку, связанную с ОЗУ, или иную логическую ошибку с точностью до компонента, который эту ошибку вызвал.

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

Рис. 6 - В микроядерной ОС сбои в ОЗУ для драйверов, стеков протоколов и других службах не приведут к нарушению работы других процессов или ядра. Более того, ОС может мгновенно обнаружить неразрешенную попытку доступа к памяти и указать, со стороны какого кода предпринята эта попытка.

По сравнению с обычным ядром ОС микроядру свойственно необычайно малое среднее время восстановления после сбоя (Mean Time to Repair, MTTR). Рассмотрим, что происходит при сбое в работе драйвера устройства: ОС может завершить работу драйвера, восстановить используемые драйвером ресурсы и перезапустить драйвер. Обычно на это уходит несколько миллисекунд. В обычной монолитной операционной системе устройство должно быть перезагружено – этот процесс может занять от нескольких секунд до нескольких минут.

Заключительные замечания

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

Между тем, инструменты динамического анализа поддерживают этапы интеграции и тестирования, сообщая в среду разработки об ошибках (или потенциальных проблемах), возникающих при исполнении программы. Эти инструменты предоставляют также полную информацию по обратной трассировке до места возникновения ошибки. Используя эту информацию, разработчики могут выполнить "посмертную" отладку таинственного отказа программы или краха системы за значительно меньший интервал времени. При динамическом анализе через трассировку стека и переменных могут быть выявлены основополагающие причины проблемы – эта лучше, чем повсеместно использовать операторы “if (ptr != NULL)” для предотвращения и обхода аварийных ситуаций.

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

Библиография

  • Eigler, Frank Ch., “Mudflap: Pointer Use Checking for C/C++”, Proceedings of the GCC Developers Summit 2003, pg. 57-70. http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf
  • “Heap Analysis: Making Memory Errors a Thing of the Past”, QNX Neutrino RTOS Programmer’s Guide. http://pegasus.ott.qnx.com/download/download/16853/neutrino_prog.pdf

О компании QNX Software Systems

QNX Software Systems является одной из дочерних компаний Harman International и ведущим глобальным поставщиком инновационных технологий для встраиваемых систем, включая связующее ПО, инструментальные средства разработки и операционные системы. ОСРВ QNX® Neutrino®, комплект разработчика QNX Momentics® и связующее ПО QNX Aviage®, основанные на модульной архитектуре, образуют самый надежный и масштабируемый программный комплекс для создания высокопроизводительных встраиваемых систем. Глобальные компании-лидеры, такие как Cisco, Daimler, General Electric, Lockheed Martin и Siemens, широко используют технологии QNX в сетевых маршрутизаторах, медицинской аппаратуре, телематических блоках автомобилей, системах безопасности и защиты, в промышленных роботах и других приложениях для ответственных и критически важных задач. Головной офис компании находится в г. Оттава (Канада), а дистрибьюторы продукции расположены в более чем 100 странах по всему миру.

О компании Klocwork

Продукты компании Klocwork предназначены для автоматизированного анализа статического кода, выявления и предотвращения дефектов программного обеспечения и проблем безопасности. Наша продукция предоставляет коллективам разработчиков инструментарий для выявления коренных причин недостатков качества и безопасности программного обеспечения, для отслеживания и предотвращения этих недостатков на протяжении всего процесса разработки. Запатентованная технология компании Klocwork была создана в 1996 г. и обеспечила высокий коэффициент окупаемости инвестиций (ROI) для более чем 80 клиентов, многие из которых входят в рейтинг крупнейших 500 компаний журнала Fortune и предлагают среды разработки программного обеспечения, пользующиеся наибольшим спросом в мире. Klocwork является частной компанией и имеет офисы в Берлингтоне, Сан Хосе, Чикаго, Далласе (США) и Оттаве (Канада).


Аннотация

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

Введение

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

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

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

  • Надежность - меньшее количество ошибок в тестируемой программе.
  • Удобство сопровождения - более понятный код, который легко изменять и усовершенствовать.
  • Мобильность - гибкость тестируемой программы при запуске на различных платформах.
  • Удобочитаемость - сокращение времени, необходимого для понимания кода.

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

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

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

Процесс анализа

Процесс статического анализа состоит из двух основных шагов: создания дерева кода (также называемого ) и анализа этого дерева.

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

В общем случае дерево строится только для анализируемого фрагмента кода (например, для какой-то конкретной функции). Для того чтобы создать дерево код обрабатывается сначала , а затем .

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

Рассмотрим примерный алгоритм определения типа лексемы.

Если первый символ лексемы является цифрой, лексема считается числом, если этот символ является знаком "минус", то это - отрицательное число. Если лексема является числом, она может быть числом целым или дробным. Если в числе содержится буква E, определяющая экспоненциальное представление, или десятичная точка, число считается дробным, в противном случае - целым. Заметим, что при этом может возникнуть лексическая ошибка - если в анализируемом исходном коде содержится лексема "4xyz", лексер сочтет ее целым числом 4. Это породит синтаксическую ошибку, которую сможет выявить синтаксический анализатор. Однако подобные ошибки могут обнаруживаться и лексером.

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

Наконец, если лексема не является строкой, она должна быть идентификатором, зарезервированным словом, или зарезервированным символом. Если лексема не подходит и под эти категории, возникает лексическая ошибка. Лексер не будет обрабатывать эту ошибку самостоятельно - он только сообщит синтаксическому анализатору, что обнаружена лексема неизвестного типа. Обработкой этой ошибки займется синтаксический анализатор.

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

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

Int Func(){return 0;}

Лексер обработает эту строку и разобьет ее на лексемы как показано в таблице 1:

Таблица 1 - Лексемы строки "int Func(){return 0};".

Строка будет распознана как 8 корректных лексем, и эти лексемы будут переданы синтаксическому анализатору.

Этот анализатор просмотрит контекст и выяснит, что данный набор лексем является объявлением функции, которая не принимает никаких параметров, возвращает целое число, и это число всегда равно 0.

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

Однако процесс построения дерева кода не сводится к простому представлению лексем в виде дерева. Рассмотрим этот процесс подробнее.

Дерево кода

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

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

При разработке вершин дерева в первую очередь обычно определяется уровень модульности. Иными словами, определяется, будут ли все конструкции языка представлены вершинами одного типа, различаемыми по значениям. В качестве примера рассмотрим представление бинарных арифметических операций. Один вариант - использовать для всех бинарных операций одинаковые вершины, одним из атрибутов которых будет тип операции, например, "+". Другой вариант - использовать для разных операций вершины различного типа. В объектно-ориентированном языке это могут быть классы вроде AddBinary, SubstractBinary, MultipleBinary, и т. п., наследуемые от абстрактного базового класса Binary.

В качестве примера разберем два выражения: 1 + 2 * 3 + 4 * 5 и 1+ 2 * (3 + 4) * 5 (см. рисунок 1).

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

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

Методы статического анализа

Существует множество различных методов , в частности, анализ с , анализ потока данных, анализ потока данных с выбором пути и т. д. Конкретные реализации этих методов различны в разных анализаторах. Тем не менее, статические анализаторы для различных языков программирования могут использовать один и тот же базовый код (инфраструктуру). Эти инфраструктуры содержат набор основных алгоритмов, которые могут использоваться в разных анализаторах кода вне зависимости от конкретных задач и анализируемого языка. Набор поддерживаемых методов и конкретная реализация этих методов, опять же, будет зависеть от конкретной инфраструктуры. Например, инфраструктура может позволять легко создавать анализатор, использующий обход дерева кода, но не поддерживать анализ потока данных .

Хотя все три перечисленные выше метода статического анализа используют дерево кода, построенное синтаксическим анализатором, эти методы различаются по своим задачам и алгоритмам.

Анализ с обходом дерева, как видно из названия, выполняется путем обхода дерева кода и проведения проверок на предмет соответствия кода принятому стандарту кодирования, указанному в виде набора правил и рекомендаций. Именно этот тип анализа проводят компиляторы.

Анализ потока данных можно описать как процесс сбора информации об использовании, определении и зависимостях данных в анализируемой программе. При анализе потока данных используется граф потока команд, генерируемый на основе дерева кода. Этот граф представляет все возможные пути выполнения данной программы: вершины обозначают "прямолинейные", без каких бы то ни было переходов, фрагменты кода, а ребра - возможную передачу управления между этими фрагментами. Поскольку анализ выполняется без запуска проверяемой программы, точно определить результат ее выполнения невозможно. Иными словами, невозможно выяснить, по какому именно пути будет передаваться управление. Поэтому алгоритмы анализа потока данных аппроксимируют возможное поведение, например, рассматривая обе ветви оператора if-then-else, или выполняя с определенной точностью тело цикла while. Ограничение точности существует всегда, поскольку уравнения потока данных записываются для некоторого набора переменных, и количество этих переменных должно быть ограничено, поскольку мы рассматриваем лишь программы с конечным набором операторов. Следовательно, для количества неизвестных всегда существует некий верхний предел, дающий ограничение точности. С точки зрения графа потока команд при статическом анализе все возможные пути выполнения программы считаются действительными. Из-за этого допущения при анализе потока данных можно получать лишь приблизительные решения для ограниченного набора задач .

Описанный выше алгоритм анализа потока данных не различает путей, поскольку все возможные пути, вне зависимости от того реальны они, или нет, будут ли они выполняться часто, или редко, все равно приводят к решению. На практике, однако, выполняется лишь малая часть потенциально возможных путей. Более того, самый часто выполняемый код, как правило, составляет еще меньшее подмножество всех возможных путей. Логично сократить анализируемый граф потока команд и уменьшить таким образом объем вычислений, анализируя лишь некоторое подмножество возможных путей. Анализ с выбором путей проводится по сокращенному графу потока команд, в котором нет невозможных путей и путей, не содержащих "опасного" кода. Критерии выбора путей различны в различных анализаторах. Например, анализатор может рассматривать лишь пути, содержащие объявления динамических массивов, считая такие объявления "опасными" согласно настройкам анализатора.

Заключение

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

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

Библиографический список

  • Dirk Giesen Philosophy and practical implementation of static analyzer tools . -Electronic data. -Dirk Giesen, cop. 1998.
  • James Alan Farrell Compiler Basics . -Electronic data. -James Alan Farrell, cop 1995. -Access mode: http://www.cs.man.ac.uk/~pjj/farrell/compmain.html
  • Joel Jones Abstract syntax tree implementation idioms . -Proceedings of the 10th Conference on Pattern Languages of Programs 2003, cop 2003.
  • Ciera Nicole Christopher Evaluating Static Analysis Frameworks .- Ciera Nicole, cop. 2006.
  • Leon Moonen A Generic Architecture for Data Flow Analysis to Support Reverse Engineering . - Proceedings of the 2nd International Workshop on the Theory and Practice of Algebraic Specifications, cop. 1997.

При написании кода на C и C++ люди допускают ошибки. Многие из этих ошибок находятся благодаря -Wall , ассертам, тестам, дотошному code review, предупреждениям со стороны IDE, сборкой проекта разными компиляторами под разные ОС, работающие на разном железе, и так далее. Но даже при использовании всех этих мер ошибки часто остаются незамеченными. Немного улучшить положение дел позволяет статический анализ кода. В этой заметке мы познакомимся с некоторыми инструментами для произведения этого самого статического анализа.

CppCheck

CppCheck является бесплатным кроссплатформенным статическим анализатором с открытым исходным кодом (GPLv3). Он доступен в пакетах многих *nix систем из коробки. Также CppCheck умеет интегрироваться со многими IDE. На момент написания этих строк CppCheck является живым, развивающимся проектом.

Пример использования:

cppcheck ./ src/

Пример вывода:

: (error) Common realloc mistake: "numarr" nulled but not
freed upon failure

: (error) Dangerous usage of "n" (strncpy doesn"t always
null-terminate it)

CppCheck хорош тем, что он довольно быстро работает. Нет повода не добавить его прогон в систему непрерывной интеграции , чтобы исправлять прямо все-все-все выводимые им предупреждения. Даже несмотря на то, что многие из них на практике оказываются ложно-положительными срабатываниями.

Clang Static Analyzer

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

Пример построения отчета для PostgreSQL :

CC =/ usr/ local/ bin/ clang38 CFLAGS ="-O0 -g" \
./ configure --enable-cassert --enable-debug
gmake clean
mkdir ../ report-201604 /
/ usr/ local/ bin/ scan-build38 -o ../ report-201604 / gmake -j2

Пример построения отчета для ядра FreeBSD :

# использование своего MAKEOBJDIR позволяет собирать ядро не под рутом
mkdir / tmp/ freebsd-obj
# сама сборка
COMPILER_TYPE =clang / usr/ local/ bin/ scan-build38 -o ../ report-201604 / \
make buildkernel KERNCONF =GENERIC MAKEOBJDIRPREFIX =/ tmp/ freebsd-obj

Идея, как несложно догадаться, заключается в том, чтобы сделать clean, а затем запустить сборку под scan-build.

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

В данном контексте не могу не отметить, что в мире Clang/LLVM есть еще и средства динамического анализа, так называемые «санитайзеры». Их много, они находят очень крутые ошибки и работают быстрее, чем Valgrind (правда, только под Linux). К сожалению, обсуждение санитайзеров выходит за рамки настоящей заметки, поэтому ознакомьтесь с ними самостоятельно .

PVS-Studio

Закрытый статический анализатор, распространяемый за деньги. PVS-Studio работает только под Windows и только с Visual Studio. Есть многочисленные сведения о существовании Linux-версии, но на официальном сайте она не доступна. Насколько я понял, цена лицензии обсуждается индивидуально с каждым клиентом. Доступен триал.

Я протестировал PVS-Studio 6.02 на Windows 7 SP1 работающей под KVM с установленной Visual Studio 2013 Express Edition. Во время установки PVS-Studio также дополнительно скачался.NET Framework 4.6. Выглядит это примерно так. Вы открываете проект (я тестировал на PostgreSQL) в Visual Studio, в PVS-Studio жмете «сейчас я начну собирать проект», затем в Visual Studio нажимаете Build, по окончании сборки в PVS-Studio жмете «я закончил» и смотрите отчет.

PVS-Studio действительно находит очень крутые ошибки, которые Clang Static Analyzer не видит (например). Также очень понравился интерфейс, позволяющий сортировать и фильтровать ошибки по их типу, серьезности, файлу, в котором они были найдены, и так далее.

С одной стороны, печалит, что чтобы использовать PVS-Studio, проект должен уметь собираться под Windows. С другой стороны, использовать в проекте CMake и собирать-тестировать его под разными ОС, включая Windows, при любом раскладе является очень неплохой затеей. Так что, пожалуй, это не такой уж и большой недостаток. Кроме того, по следующим ссылкам можно найти кое-какие подсказки касательно того, как людям удавалось прогонять PVS-Studio на проектах, которые не собираются под Windows: раз , два , три , четыре .

Дополнение: Попробовал бета-версию PVS-Studio для Linux. Пользоваться ею оказалось очень просто . Создаем pvs.conf примерно такого содержания:

lic-file=/home/afiskon/PVS-Studio.lic
output-file=/home/afiskon/postgresql/pvs-output.log

Затем говорим:

make clean
./ configure ...
pvs-studio-analyzer trace -- make
# будет создан большой (у меня ~40 Мб) файл strace_out
pvs-studio-analyzer analyze --cfg ./ pvs.conf
plog-converter -t tasklist -o result.task pvs-output.log

Дополнение: PVS-Studio для Linux вышел из беты и теперь доступен всем желающим .

Coverity Scan

Coverity считается одним из самых навороченных (а следовательно и дорогих) статических анализаторов. К сожалению, на официальном сайте невозможно скачать даже его триал-версию. Можно заполнить форму, и если вы какой-нибудь IBM, с вами может быть свяжутся. При очень сильном желании Coverity какой-нибудь доисторической версии можно найти через неофициальные каналы. Он бывает для Windows и Linux, работает примерно по тому же принципу, что и PVS-Studio. Но без серийника или лекарства отчеты Coverity вам не покажет. А чтобы найти серийник или лекарство, нужно иметь не просто очень сильное желание, а очень-очень-очень сильное.

К счастью, у Coverity есть SaaS версия — Coverity Scan. Мало того, что Coverity Scan доступен для простых смертных, он еще и совершенно бесплатен. Привязки к конкретной платформе нет. Однако анализировать с помощью Coverity Scan разрешается только открытые проекты.

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

Отчеты строятся таким образом. Сначала вы локально собираете свой проект под специальной утилитой Coverity Build Tool. Утилита эта аналогична scan-build из Clang Static Analyzer и доступна под все мыслимые платформы, включая всякую экзотику типа FreeBSD или даже NetBSD.

Установка Coverity Build Tool:

tar -xvzf cov-analysis-linux64-7.7.0.4.tar.gz
export PATH =/ home/ eax/ temp/ cov-analysis-linux64-7.7.0.4/ bin:$PATH

Готовим тестовый проект (я использовал код из заметки Продолжаем изучение OpenGL: простой вывод текста):

git clone git @ github.com:afiskon/ c-opengl-text.git
cd c-opengl-text
git submodule init
git submodule update
mkdir build
cd build
cmake ..

Затем собираем проект под cov-build:

cov-build --dir cov-int make -j2 demo emdconv

Важно! Не меняйте название директории cov-int.

Архивируем директорию cov-int:

tar -cvzf c-opengl-text.tgz cov-int

Заливаем архив через форму Upload a Project Build. Также на сайте Coverity Scan есть инструкции по автоматизации этого шага при помощи curl. Ждем немного, и можно смотреть результаты анализа. Примите во внимание, что чтобы пройти модерацию, нужно отправить на анализ хотя бы один билд.

Ошибки Coverity Scan ищет очень хорошо. Уж точно лучше, чем Clang Static Analyzer. При этом ложно-положительные срабатывания есть, но их намного меньше. Что удобно, в веб-интерфейсе есть что-то вроде встроенного багтрекера, позволяющего присваивать ошибкам серьезность, ответственного за их исправление и подобные вещи. Видно, какие ошибки новые, а какие уже были в предыдущих билдах. Ложно-положительные срабатывания можно отметить как таковые и скрыть.

Заметьте, что чтобы проанализировать проект в Coverity Scan, не обязательно быть его владельцем. Мне лично вполне успешно удалось проанализировать код PostgreSQL без присоединения к уже существующему проекту. Думается также, что при сильном желании (например, используя сабмодули Git), можно подсунуть на проверку немного и не очень-то открытого кода.

Заключение

Вот еще несколько статических анализаторов, не попавших в обзор:

Каждый из рассмотренных анализаторов находят такие ошибки, которые не находят другие. Поэтому в идеале лучше использовать их сразу все. Делать это вот прямо постоянно, скорее всего, объективно не получится. Но делать хотя бы один прогон перед каждым релизом точно будет не лишним. При этом Clang Static Analyzer выглядит наиболее универсальным и при этом достаточно мощным. Если вас интересует один анализатор, который нужно обязательно использовать в любом проекте, используйте его. Но все же я бы рекомендовал дополнительно использовать как минимум PVS-Studio или Coverity Scan.

А какие статические анализаторы вы пробовали и/или регулярно использовали и каковы ваши впечатления от них?



Популярное в рубрике:
Самсунг Галакси перезагружается сам по себе — Решения Galaxy note 4 перезагружается сам по себе
Самсунг Галакси перезагружается сам по себе — Решения Galaxy note...
читать
Основные возможности Kaspersky Rescue Disk
Основные возможности Kaspersky Rescue Disk
читать
Макбук не подключается к wifi Макбук не видит вай фай
Макбук не подключается к wifi Макбук не видит вай фай
читать
Как заработать на WebMoney
Как заработать на WebMoney
читать

Последние Статьи
"Супра", планшет: отзывы покупателей
читать
Местонахождения судов в реальном времени
читать
Лучшие программы для Android Запись звонков от...
читать
Удаляем не читателей в Твиттере
читать
Подключаем интернет на ноутбуке: все возможные...
читать
Samsung Galaxy S IV – новый флагман...
читать
Как происходит управление скоростью вращения...
читать
Магнитный кабель USB TYPE-C с круглым...
читать
Top