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



    Обычно мы проверяем с помощью 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. Новый механизм подавления ненужных сообщений анализатора
    PVS-Studio
    Статический анализ кода для C, C++, C# и Java

    Комментарии 8

      0
      PVS-Studio Standalone ведь проверяется с помощью PVS-Studio, так?
      Можете рассказать, почему PVS-Studio не обнаружил в исходных текстах PVS-Studio Standalone (CLMonitoring) случаи утечки памяти?
      Это недостаток какой-то диагностики?

      Судя по "Истории версий PVS-Studio", в крайней версии (5.22) добавлена только диагностика V718. The 'Foo' function should not be called from 'DllMain' function, но она, судя по тексту описания, связана не с утечками памяти.
        +5
        1) PVS-Studio Standalone написан на C#. PVS-Studio не анализаирует C#.
        2) PVS-Studio не ищет утечки памяти, так как это неблагородная (сложная/невыполнимая) задача для статических анализаторов кода. Каждой методологии — своё (пояснение, пояснение).
          +4
          Можете рассказать, почему PVS-Studio не обнаружил в исходных текстах PVS-Studio Standalone (CLMonitoring) случаи утечки памяти?


          Статический анализ плохо подходит для ловли утечек памяти. Динамический анализ намного лучше в этой задаче.

          Судя по «Истории версий PVS-Studio»...

          В историю попадает далеко не все. А только то, что может быть интересно конечному пользователю.
          –9
          Где можно скачать лекарство от Pvs-studio ?
            0
            было бы такое решение для пакетов оракл…
              0
              Мы не используем C/C++ в разработке, и по-большему счету я сам тоже никогда не писал «промышленно» на этих языках, но всегда с читаю ваши статьи о разборе ошибок в OpenSource проектах — интересно. Спасибо.

              И чем дальше, тем чаще возникает вопрос — вы про трансформацию в SaaS ведь наверняка думали? За последние пару лет, очень много инструментов перешли на эту модель. Некоторые из них, умеют интегрироваться с github/bitbucket и если проект OpenSource предоставляют небольшое количество услуг бесплатно, и что самое важное, буквально в два-три клика мышкой.

              Читая сейчас о том, что ускорили работу с 15 часов до 9, про старые форматы путей, подумал — если в такой SaaS «нахлынут» OpenSource проекты, разработчики сами начнут разбираться как это всё запускать и что с этим дальше делать, сколько еще такого рода узких мест вы найдете…

              Если думали, и есть что рассказать, расскажите, интересно.
                0
                Сейчас это направление нам не интересно.

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

                Самое читаемое