CodeChecker: анализируем большой проект на С++ быстро, эффективно и бесплатно

CodeCheсker предоставляет удобный интерфейс запуска и конфигурации статических анализаторов на Linux или macOS. С помощью него можно запускать анализаторы кода на C/C++ — Clang-Tidy, Clang Static Analyzer, Cppcheck и GCC Static Analyzer — в любой комбинации. А еще — включать и выключать различные проверки этих анализаторов. Результаты проверок можно изучать в удобном веб-интерфейсе.

Чем он нам понравился:

• С ним просто запускать анализаторы. Статических анализаторов немало, но иногда их неудобно использовать: настраивать конфигурационные файлы долго, нет простого способа запуска чекера и парсинга результатов. CodeChecker исключает эти проблемы, предоставляя удобный интерфейс запуска и конфигурации через аргументы командной строки.
• Его просто установить. CodeChecker — это python-пакет, ставится просто и не требует никаких настроек. Можно использовать «из коробки».

Поскольку CodeChecker — это python-пакет, устанавливается он самым обычным pip3 (сам пакет доступен на pypi):

pip3 install codechecker

Можно установить пакет в виртуальном окружении или воспользоваться pipx, который самостоятельно создаст venv:

pipx install CodeChecker

Еще один вариант — установка через пакетный менеджер Snap:

sudo snap install codechecker --classic

Обратите внимание, что название инструмента в консоли в таком случае нужно писать именно прописными буквами.

Еще больше способов установки (в основном напрямую) описаны в документации CodeChecker. Также его можно запустить в Docker-контейнере или в редакторе Visual Studio Code.

Существует несколько способов запуска анализаторов с помощью CodeChecker, но мы выберем самый простой — через передачу compilation database (файла compile_commands.json). По сути, это просто данные о структуре проекта в одном файле. Их можно передавать, например, своей IDE, если она не видит зависимостей и из-за этого работает некорректно.

Сгенерировать этот файл можно разными способами. Например, если вы используете CMake, то можно просто прописать cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON. в рабочей директории. Но у нас Linux, поэтому воспользуемся, возможно, более сложным способом — утилитой Bear, которая генерирует базу данных компиляции для инструментов clang. Чтобы сгенерить compile_commands.json, заходим в рабочую директорию и пишем: bear -- <ваша-команда-для-билда-проекта>, в нашем случае bear -- make. Готово, в этой же директории получаем compile_commands.json.

Для запуска анализаторов будем использовать команду analyze. В общей команде нужно указать следующее:

• путь до файла compile_commands.json,
• названия анализаторов, которые хотим запустить,
• настройки чекеров,
• папку, куда сгенерировать результат.

Файл compile_commands.json у нас уже есть, разберемся c анализаторами.

В CodeChecker доступны четыре анализатора — подробнее о каждом я расскажу позже:

• Clang-Tidy — ставится дефолтным пакетом или вместе с Сlang,
• Clang Static Analyzer — ставится вместе с Сlang,
• Cppcheck — ставится дефолтным пакетом,
• GCC Static Analyzer — ставится вместе с GNU Compiler Collection.

По дефолту CodeChecker запустит все доступные анализаторы. Прописать конкретный набор анализаторов можно во флаг --analyzers. Например, --analyzers gcc clangsa.

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

Есть три способа включить или выключить проверку:

• через конкретный чекер,
• через группу чекеров, которые просто объединяют чекеры в одну сущность,
• через соответствующий профиль.

Для включения/выключения чекеров используют флаги --enable и --disable и их комбинации. Так, с помощью --enable-all и --disable-all можно включить или выключить все чекеры (за исключением тех, что включаются вручную). Эти флаги применяются последовательно, так что их можно комбинировать для нужных настроек.

Например, после --disable-all --enable alpha.unix.PthreadLock включится только чекер PthreadLock на многопоточность.

Итоговая команда запуска может выглядеть так:

CodeChecker analyze ./compile_commands.json --analyzers clangsa --enable=alpha --enable=sensitive --output ./reports

Здесь мы запускаем Clang Static Analyzer в режиме sensitive с alpha-чекерами. Результаты анализа можно будет посмотреть в папке reports.

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

Из четырех анализаторов, входящих в CodeChecker, этот дал нам больше всего полезного «выхлопа», причем разностороннего. Тут и проверки использования STL (например, использование итератора, вышедшего за конец контейнера), и обнаружение дедлоков при работе с мьютексами, и проверки на NULL dereference. Чтобы посмотреть полезные чекеры и группы чекеров, доступные для этого анализатора, используйте команду:

clang -cc1 -analyzer-checker-help

Анализатор прорабатывает код довольно быстро, даже с полным листом чекеров, — на наш проект с немалым числом строк кода он тратил 2−3 минуты. А еще он яснее всего подсказывает, где именно в коде он нашел ошибку.

Кроме того, у анализатора есть уникальная проверка cross-translation unit, которая включается с помощью флага --ctu. Этот режим позволяет ему расширить область видимости анализа на соседние единицы трансляции. Подробнее про конфигурирование этого анализатора можно прочитать здесь.

В итоге большинство багов и опечаток нам помог исправить именно Clang SA.

При использовании Clang-Tidy нужно быть готовым к километровому списку ошибок даже на дефолтных настройках чекеров. Анализатор ругается буквально на каждый чих, будь то неявный каст у целочисленных типов или неиспользованное значение snprintf (). Это не делает его бесполезным, но надо быть готовым, что результаты придется разгребать и выцеплять «пинцетом» действительно полезную информацию.

Еще Clang-Tidy — самый долгий из анализаторов: с дефолтными чекерами проверка может занять 30 минут. А с включением всех чекеров анализ кода может зависнуть на долгое время. Например, в наших тестах он не «проснулся» даже за час.

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

Чекеры для Clang-Tidy можно увидеть с помощью команды:

clang-tidy --list-checks

На бумаге CppCheck считают сильным анализатором, который минимизирует false-positive срабатывания. На деле он указывает на синтаксические ошибки там, где их нет, — например, при использовании varargs (variable arguments list). И в целом, дает довольно мало полезного знания о коде.

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

Этот анализатор для нашего проекта не подошел совсем, потому что GCC SА не заточен под C++, а большая часть проекта написана именно на «плюсах». В теории код на C этот анализатор должен анализировать хорошо и выдавать что-то полезное. Если это ваш случай, проверьте ради эксперимента. Но в плюсах, увы, он ничего не замечает, причем не имеет значения, путь до какого бинарника мы ему передаем.

Хочется упомянуть еще один статический анализатор, про который мы узнали из описания CodeChecker — Facebook* Infer (*компания Facebook принадлежит организации Meta, признанной экстремистской на территории РФ). Он не запускается из интерфейса CodeChecker, но мы решили опробовать его отдельно. В отличие от предыдущих анализаторов, он может проверять код не только на C/C++, но и на других языках — например, Java и Objective-C.

Для запуска нам потребуется все тот же compile_commands.json. Просто прописываем:

infer --compilation-database ./compile_commands.json

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

Этот анализатор нам понравился. Facebook Infer показал много мест с неинициализированными и неиспользованными переменными, ситуациями гонки и лишними копированиями значений. Работает быстро, примерно как ClangSA (2−3 минуты), хоть настроек у него и мало.

Результаты можно посмотреть в .txt-файлике, сгенеренном анализаторм. А если хочется более приятного интерфейса, можно спарсить результаты Facebook Infer с помощью CodeChecker, Как парсить результаты — расскажу далее.

После успешного анализа результаты необходимо обработать. В CodeChecker это легко сделать с помощью команды parse:

CodeChecker parse --export html --output ./reports_html ./reports

Во флаге --export указываем формат, в котором хотим получить результат, в нашем случае это html. Также прописываем папку, куда сгенерить результаты обработки, и, конечно, указываем путь до папки, где мы хотим увидеть результаты анализа.

Теперь можно посмотреть результаты и статистику по анализу на красивой html-странице.

• В колонке File можно нажать на соответствующую запись — откроется вкладка с кодом. В ней будет поэтапно показано, что не понравилось анализатору и приводит к ошибке.
• В колонке Severity указывается степень «тяжести» той или иной ошибки.
• В колонке Message описана проблема, иногда с указанием конкретных переменных/структур.

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

Статические анализаторы в составе CodeChecker помогли нам найти и исправить более 300 ошибок (без учета false-positive результатов). Для сравнения, коммерческое решение подсветило около 120 проблем, 99% из которых false-positive. А интерфейс инструмента в разы облегчил их использование.

Если хотите максимальной пользы для проекта в короткие сроки, рекомендую запустить ClangSA на sensitive/extreme настройках, а потом дополнительно прогнать код через Facebook Infer. Если есть время и хочется немного «причесать» код, можно подключить и остальные анализаторы — Clang-Tidy, CppCheck и даже GCC SA. Главное, что все это не требует ни покупки лицензий, ни долгих настроек.