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

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

![0307_PVS-StudioIssuesInLibreOffice_ru/image1.png](https://import.viva64.com/docx/blog/0307_PVS-StudioIssuesInLibreOffice_ru/image1.png)

## Введение

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

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

[PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/) \- статический анализатор, выявляющий ошибки в исходном коде приложений на языке C/C\+\+\. Возможности применения и интеграции анализатора постоянно расширяются и, кроме демонстрации возможностей, open\-source проекты выступают непредвзятыми тестировщиками для анализатора\.

Проект [LibreOffice](https://www.libreoffice.org/) оказался хорошим тестом для статического анализатора и заставил поработать каждого из команды PVS\-Studio\.

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

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

LibreOffice собирается с помощью MS Visual C\+\+ 2013 в Cygwin\. Утилита PVS\-Studio Standalone относительно недавно обзавелась возможностью проверять любые проекты, не вдаваясь в подробности сборочной системы, достаточно просто включить "Compiler Monitoring" и запустить сборку проекта\. Подробнее об этой возможности можно прочитать в статье: [PVS\-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор\. Легко и "из коробки"](https://pvs-studio.ru/ru/blog/posts/0243/)\. Если вкратце, то из запущенных процессов в 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](https://github.com/protocolbuffers/protobuf), которая отлично справляется с той же задачей\.

## Заключение

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

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

1. [PVS\-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор\. Легко и "из коробки"](https://pvs-studio.ru/ru/blog/posts/0243/)
1. [Новый механизм подавления ненужных сообщений анализатора](https://pvs-studio.ru/ru/blog/posts/0289/)