Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Вебинар: Базовые сценарии интеграции SAST решения в legacy-проект на примере PVS-Studio - 18.04
Обычно мы проверяем с помощью 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, который помог нам сделать наш анализатор лучше!
0
0
0
0