Как мы баг в PVS-Studio искали или 278 Гигабайтов логов

Предлагаем вашему вниманию интересную историю о поиске бага внутри анализатора PVS-Studio. Да, мы тоже допускаем ошибки, но мы готовы засучить рукава и залезть в самую глубину "кроличьей норы".

Небольшое предисловие

Наш коллега уже рассказывал про нашу техническую поддержку. Но всегда интересно послушать какие-то истории, и они у нас есть.

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

На текущий момент мы имеем пять отделов разработки:

• отдел разработки C и C++ анализатора;
• отдел разработки C# анализатора;
• отдел Tools & DevOps;
• отдел web-разработки;
• отдел разработки CRM-системы.

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

• разработка ядра анализатора: улучшение парсера и системы типов, улучшение анализа потока данных и символьных вычислений и др. Кстати, недавно мы написали несколько статей о различных доработках: межмодульный анализ, борьба с легаси в C и C++ анализаторе, улучшение анализа потока данных в C# анализаторе;
• написание новых диагностических правил и улучшение старых.

Третий отдел занимается разработкой и поддержкой всех связующих компонентов для наших анализаторов:

• интеграция с популярными IDE – Visual Studio 2010-2022, IntelliJ IDEA, Rider, CLion;
• интеграция с платформой непрерывного контроля качества SonarQube;
• интеграция с игровыми движками Unreal Engine и Unity;
• утилита для конвертации отчёта анализатора в различные форматы – SARIF, TeamCity, HTML, FullHTML и др.;
• утилита для оповещения команд разработчиков о найденных подозрительных местах в коде.

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

Теперь же познакомимся поближе именно с поддержкой C++ отдела. Обращения в поддержку по C и C++ анализатору можно разделить на следующие виды:

1. Диагностическое правило выдаёт ложноположительное срабатывание. Разработчику сильно повезёт, если пользователь присылает пример для воспроизведения. В большинстве случаев присланные по переписке примеры максимально упрощаются, и поправить диагностику иногда становится испытанием.
2. Анализатор не выдаёт срабатывание на пользовательском примере. Здесь возможны два исхода:
   • анализатор молчит специально. Здесь вы можете подробнее ознакомиться с причинами, почему он это делает в некоторых ситуациях;
   • пользователь прав. Мы получаем от него необходимые уточнения по примеру, а дальше решаем: либо дорабатываем существующую диагностику, либо пишем новую.
3. Анализатор не разобрал какую-либо конструкцию языка C и C++. Грамматики этих языков позволяют писать очень запутанный код, и порой анализатор не справляется. В таких ситуациях пользователи присылают нам ошибки V001. Чтобы исправлять такие проблемы, обычно мы запрашиваем минимально воспроизводимые примеры или промежуточные файлы для анализа (*.i и *.cfg файлы).
4. Падение ядра C и C++ анализатора. От ошибок не застрахован никто, падения иногда происходят. С нашим анализатором тоже (V003). Здесь очень помогают пользователи, присылая стектрейсы, дампы памяти или промежуточные файлы для анализа.
5. Не работает один из многих сценариев использования продукта. Проблемы подобного рода обладают широчайшим разнообразием, и описать их всех в паре предложений не удастся.

История, о которой говорится в заголовке статьи, началась как раз с письма пользователя в поддержку. Клиент жаловался на зависание инкрементального анализа, поэтому далее речь пойдёт именно о последнем варианте.

Инкрементальный анализ, который не смог

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

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

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

Command "/usr/bin/c++ -DBOOST_ASIO_DYN_LINK ...." returned code 3.

Сия запись означает, что препроцессор отвалился по таймауту. Мы запускаем препроцессор на компилируемых файлах проекта для того, чтобы раскрыть макросы и сделать подстановку файлов, указанных в директивах #include. И только после этого мы запускаем анализ на полученных файлах с некоторой дополнительной информацией (целевая платформа, пути до исключаемых директорий из анализа и т.д.).

Многим C++ разработчикам знакома боль при компиляции проектов с подключенными библиотеками Boost – время сборки сильно повышается. Препроцессирование также страдает от этого. Как видно из вышеприведенной команды, пользователь использует в проекте Boost. Ранее нам также поступали письма с подобной проблемой: при высокой загрузке процессора файлы не успевают препроцессироваться.

У нас уже достаточно давно витала в воздухе идея убрать это жёсткое ограничение с препроцессированием в 30 секунд. И снова похожий кейс. Решено – убираем таймаут. Можно высылать пользователю бету и ждать ответа.

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

• ранее анализ доходил до конца, но была куча V008 в отчёте;
• теперь анализ зависает на этапе парсинга тех же самых файлов (примерно на 86 % прогресса).

Что ж, проблема оказалась более сложной, продолжаем копать.

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

exclude-path=*/generated/sip*
exclude-path=*/pacs/soapserver/generated/*
exclude-path=*/soap_engine/*
exclude-path=*/tech1utils/tests/googlemock/*
exclude-path=*/sdk-common/*
exclude-path=*/tech1grabbers/SDKs/*
# ....
# 200+ similar entries
# ....
exclude-path=/mnt/nvme/jenkins/workspace/..../lpr-ide.cpp

Настройка exclude-path позволяет подавлять предупреждения на код из third-party библиотек и тестов. В типовой ситуации пользователи указывают либо несколько путей до конкретных директорий, либо используют шаблон поиска. И количество записей редко превышает 30-40 штук. Здесь же было 200+ различных путей с исключенными файлами, включая шаблоны поиска. Мы заподозрили, что наш алгоритм исключения файлов из анализа, написанный 10+ лет назад, уже просто не мог быстро "переварить" такое количество записей в конфигурационном файле.

class PathMatcher
{
// ....
private:
  using GlobsCollection = std::set<std::string, std::less<>>;
  using PathsCollection = ???;

  GlobsCollection m_globs; // шаблоны
  PathsCollection m_paths; // обычные пути
};

/home/user/folderToExclude/fileToExclude.cpp
/home/user/folderToExclude/
|______общий префикс______|

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

Убийца – дворецкий!

Но праздновать победу (закрывать тикет) было ещё рано. Пользователь опять пишет о том же самом зависании.

Что ж, быстрые правки не помогли, приходится ещё сильнее погружаться в эту проблему. В этот раз мы решили попросить пользователя запустить нашу утилиту под strace и прислать все сформированные логи. Если кто не знает, утилита strace позволяет отследить все системные вызовы программы и многое другое. Кстати, мы же используем её для одного из вариантов внедрения анализатора в свой проект (трассировка вызовов компиляторов).

Вот команда, которой пользователь формировал логи:

strace -y -v -s 4096 -ff -o strace-logs/log.txt -- pvs-studio-analyzer ....

Он оставил программу поработать примерно на 20 минут перед убийством процесса. Поскольку во время зависания утилита strace продолжала писать информацию в логи, то их размер получился внушительный – 22795 файлов с суммарным весом в 278 ГБ (!) без сжатия.

Сначала посмотрели выхлоп strace. И сразу же увидели огромное количество вызовов nanosleep. Это означало, что дочерние процессы, порождаемые утилитой pvs-studio-analyzer, почему-то сидели в бесконечном ожидании. Мы прошерстили логи сверху вниз и таки нашли проблему:

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

В ОС Linux при открытии файла ему присваивается специальный номер – дескриптор, который затем используется для работы с ним: чтения, записи, просмотра атрибутов и т.д. Количество таких дескрипторов ограничено и определяется настройками системы.

Кстати, проблему воспроизвести очень легко. Для воспроизведения проблемы достаточно написать следующий CMakeLists.txt:

cmake_minimum_required(VERSION 3.5)
project(many-files LANGUAGES C CXX)

set(SRC "")

foreach(i RANGE 10000)
  set(file "${CMAKE_CURRENT_BINARY_DIR}/src-${i}.c")
  file(TOUCH "${file}")
  set(SRC "${SRC};${file}")
endforeach()

add_library(many-files STATIC
            ${SRC})

Далее формируем кеш в директории с CMakeLists.txt и запускаем утилиту pvs-studio-analyzer версии ниже 7.18:

cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=On
pvs-studio-analyzer analyze -f ./build/compile_commands.json -j -i -o pvs.log

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

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

Третий раз выкатив клиенту бету, мы, наконец, решили проблему с зависанием.

Заключение

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

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

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

Похожие статьи

1. Один день из жизни разработчика PVS-Studio.
2. Для тех, кто хочет поиграть в детектива: найди ошибку в функции из Midnight Commander.
3. Когда дворецкий — жертва.
4. Программные ошибки, которых не бывает.
5. Как PVS-Studio оказался внимательнее, чем три с половиной программиста.
6. В очередной раз анализатор PVS-Studio оказался внимательнее человека.