Какие баги нашёл LibreOffce в PVS-Studio?

в 7:24, , рубрики: libreoffice, pvs-studio, static code analysis, Блог компании PVS-Studio, Компиляторы, статический анализ кода
Какие баги нашёл LibreOffce в PVS-Studio? - 1

Обычно мы проверяем с помощью PVS-Studio какой-нибудь проект. В этот раз вышло по-другому. Мы проверили PVS-Studio с помощью LibreOffice :-). А потом все-таки смогли и наоборот проверить.

Введение

Статьи о проверках проектов вызывают самую разную реакцию у читателей: от «Сколько уже можно это рекламировать?» до «Огромное спасибо! PVS-Studio — действительно отличный инструмент.» Справедливости ради хочется сказать, что в проверке проекта не учувствуют специалисты по рекламе, прикладывают усилия только разработчики PVS-Studio и переводчик. Вклад анализатора в open-source, безусловно присутствует не малый. Разработчики не всегда заинтересованы в обратной связи, но письмо о проверке получают и найденные ошибки исправляют. На примере проекта LibreOffice, статья о котором тоже скоро будет доступна, хочу рассказать о влиянии проверок проектов на сам анализатор и о проделанной работе.

Об анализаторе

PVS-Studio — статический анализатор, выявляющий ошибки в исходном коде приложений на языке C/C++. Возможности применения и интеграции анализатора постоянно расширяются и, кроме демонстрации возможностей, open-source проекты выступают непредвзятыми тестировщиками для анализатора.

Проект LibreOffice оказался хорошим тестом для статического анализатора и заставил поработать каждого из команды PVS-Studio.

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

Утечка памяти

LibreOffice собирается с помощью MS Visual C++ 2013 в Cygwin. Утилита PVS-Studio Standalone относительно недавно обзавелась возможностью проверять любые проекты, не вдаваясь в подробности сборочной системы, достаточно просто включить «Compiler Monitoring» и запустить сборку проекта. Подробнее об этой возможности можно прочитать в статье: PVS-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор. Легко и «из коробки». Если вкратце, то из запущенных процессов в Windows извлекается информация, необходимая для запуска процесса в этом же окружении. Так вот для хранения строки запуска, текущей директории, переменных окружения и т.п. выделяется несколько сотен килобайт неуправляемой памяти. Если процесс относится к поддерживаемому компилятору, то информация копировалась в управляемую память, неуправляемая память в любом случае освобождалась, НО, для переменных окружения, как оказалось, этого не делалось. Для каждого процесса не освобождалось в среднем 500 килобайт. На проверяемых ранее проектах это не приводило к серьёзным проблемам (по крайней мере мы не замечали, что что-то не в порядке и пользователи не жаловались). Сборка Make'ом LibreOffice сопровождается огромным количеством запускаемых процессов, не относящихся к компилятору. За несколько часов сборки было запущено более ста тысяч процессов, в итоге «накапало» 25 гигабайт. После исправления данного места, размер памяти используемой программой мониторинга уменьшился до 1.8 гб.

Длительная проверка

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

Сложности анализа

Если анализатору не удаётся разобрать какие-нибудь конструкции в исходном коде, то он выдаёт сообщения V001 на этот файл. Такой участок кода анализатором пропускается и в очень редких случаях влияет на результаты проверки. Тем не менее, сообщения V001 на этом проекте были изучены и поправлены.

Старый формат путей

При проверке проекта были обнаружены системные пути в старом формате, например, «C:/PROGRA~2/MICROS~4.0/VC/include». Такой формат полностью поддерживается ядром анализатора и плагином, но фильтрация сообщений на системных файлах не сработала, поэтому были внесены соответствующие правки.

Неудавшаяся сериализация

Данная проблема не совсем относится к продуктам PVS-Studio. В утилите PVS-Studio Standalone, в которой проверялся LibreOffice, недавно была улучшена навигация по файлам, которая теперь позволяет переходить по включаемым заголовках и выполнять поиск типов и переменных в зависимых файлах. Все зависимости собираются во время проверки и сохраняются возле *.plog файла. К сожалению, стандартному классу System.Runtime.Serialization.Formatters.Binary.BinaryFormatter не удаётся сериализовать структуры большого объёма — возникает внутренне исключение, поэтому теперь используется библиотека Protocol Buffers, которая отлично справляется с той же задачей.

Заключение

Результатом проверки LibreOffice стала статья, которая призвана сделать лучше ещё один open-source проект, и хорошие правки в продуктах PVS-Studio. Статья о найденных ошибка в LibreOffice будет опубликована в ближайшие дни. А мы хотим сказать спасибо проекту LibreOffice, который помог нам сделать наш анализатор лучше!

Дополнительные ссылки

  1. PVS-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор. Легко и «из коробки»
  2. Новый механизм подавления ненужных сообщений анализатора
  3. Как мы тестируем анализаторы кода PVS-Studio и CppCat

Автор: SvyatoslavMC

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js