40.2
Karma
0
Rating
Павел Еремеев @Paull

Руководитель разработки

Nullable Reference типы в C# 8.0 и статический анализ

+2
Да, безусловно, ложно-положительные срабатывания неизбежны при работе статического анализатора, однако такой огромный процент скорее свидетельствует о том, что анализатор нужно дополнительно настроить перед использованием — отключить какие-то диагностики, добавить исключения на определённые файлы, unit тесты и т.п.

Nullable Reference типы в C# 8.0 и статический анализ

0
Точно не скажу, если где-то экран текста заполнить восклицательными знаками, оно падало. А размер стека у потоков, которые проверяют код, нам в анализаторе уже приходилось увеличивать (относительно значения по-умолчанию), иначе на некоторых тестовых проектах Roslyn падал, при проверке сгенерированных файлов.

Проверяем исходный код Roslyn

+1
В конце этой недели у нас запланирован релиз с поддержкой VS2019\C# 8.0. Конкретно по поддержке nullable reference и всего специфичного для них синтаксиса — анализатор будет понимать, что это такое, и что оно значит, но на работу каких-то диагностик nullable reference никакого влияния оказывать пока не будет, по крайней мере в этом релизе.

Например, если вы где-то глубоко в своём коде в не-nullable переменную всё-таки запишите null (что сделать можно с помощью оператора '!', например), и затем без проверки будете эту переменную использовать, анализатор это увидит и ругнётся. Возможно в дальнейшем наше поведение с не-nullable refernce типами будет меняться, посмотрим на отзывы пользователей, будем расширять нашу тестовую базу по мере того, как новый синтаксис будет приниматься на вооружение разработчиками.

История о том, как мы иконку PVS-Studio меняли

0
Предпоследней не хватает индивидуальности — вбейте в гугл картинки triangle logo, и вы увидите точно такую же )

Внедряйте статический анализ в процесс, а не ищите с его помощью баги

0
Потому что он не только находит но ещё и обновляет чтобы быстрее анализировалось, понятно что это для скорости. Но, если бы была настроечка включающая одну базу на sln/CmakeLists то было бы имхо попроще.

У нас можно добавлять suppress файл как на уровень sln (в случае Visual Studio проектов), так и при использовании прямой CMake интеграции (с нашим CMake модулем) Suppress файлы, однако, работают на уровне исходных файлов, поэтому если кусок кода переедет из одного файла в другой, то diff всё равно вылезет.

Также, если sln генерится CMake'ом, то добавлять в него suppress может быть неудобно — в таком случае можно в каждый ваш проект добавить общий suppress файл (т.е. все проекты будут ссылаться на один файл), а чтобы не модифицировать каждый проект по-отдельности, suppress файлы можно добавлять в проекты через общие MSBuild props'ы.

PVS-Studio 7.00

+2
На самом деле, у нас есть внутренние инструменты для «сравнения отчётов», мы их используем, например, в регрессионных тестах. Тем не менее, для конечного пользователя они, скорее всего, окажутся неудобными. Ведь при сравнении результатов работы анализатора, между получением которых прошло какое-то время, нужно учитывать, что проверяемый код мог правиться, в проверяемые файлы добавлялся код, из-за которого старый проверяемый код мог «съехать» и т.п. Поэтому, сравнение двух отчётов «в лоб» обычно неэффективно.

Существует ряд способов учитывать такие изменения, и показывать именно новые срабатывания анализатора. Например, можно использовать предоставляемые PVS-Studio различные (в зависимости от сборочной системы и платформы) способы инкрементального анализа, анализирую, в т.ч. и на коммитах, только модифицированные файлы. Можно видеть новые ошибки, которых не было в предыдущих отчётах, использую механизм подавления срабатываний (мой коллега в комментарии выше давал ссылку на его описание). Наконец, quality-control системы наподобие SonarQube (для которого у нас есть плагин), обычно предоставляют схожую функциональность. В конечном счёте, всё зависит от конкретного сценария использования анализатора.

Мы также предоставляем утилиты для рассылки писем с результатами анализа, для преобразования результатов в различные форматы и т.п., так что вставить результат в code review отчёт также не должно быть трудно.

PVS-Studio 7.00

+1
Ну во первых, наш продукт нельзя назвать чисто «32-битным» или «64-битным» — если говорить конкретно про Windows дистрибутив, то в него входит много разных утилит, некоторые из них (были) в том-числе 32-битными. Постепенно 32-битных утилит становится меньше, например наш C++ анализатор присутствовал в дистрибутиве как в виде 32-битной, так и 64-битной версий (сейчас от 32-битной версии мы отказались).

Во вторых, в папку Program Files (x86) он ставится, т.к. сам наш Windows инсталятор является 32-битным — можно сказать, что так исторически сложилось. В более старых версиях PVS-Studio, когда мы поддерживали старые IDE, такие как, например, Visual Studio 2008, возможно (я точно не ручаюсь, т.к. уже не помню), установка плагинов к таким IDE накладывала ограничения на создание чисто-64битного установщика. Также, PVS-Studio можно было установить и на 32-битную версию Windows (как я писал выше, сейчас это уже не актуально).

Так что, резюмируя, сам инсталятор, скорее всего, уже можно сделать 64-битным (возможно, мы это сделаем в будущем), однако на данный момент 32-битность инсталятора не создаёт для нас или наших пользователей каких-либо проблем, поэтому мы не видим это критичной задачей.

Короткая заметочка про PVS Studio в CI (и чего не хватает)

+2
Но для того, чтобы это всё работало, необходима поддержка коротких путей как минимум на том диске, где ведётся анализ. Для этого в реестре по пути HKLM\SYSTEM\CurrentControlSet\Control\FileSystem необходимо установить параметр NtfsDisable8dot3NameCreation (DWORD) в значение, разрешающее сохранение коротких имён файлов. Подробнее — в MSDN.
Запрет по умолчанию на короткие имена нужно для увеличения скорости работы NTFS.
Можно либо поставить значение 0 и не заморачиваться, либо 3, если задачи CI выполняются в профиле пользователя на системном разделе или где-то в другом месте на системном разделе, либо в 2 и выполнить команду fsutil 8dot3name set Z: 0 (свой диск вместо Z:), где будет развёрнуто рабочее пространство CI (к RAM-дискам тоже относится, к слову).


В релизе 6.26 мы поменяли алгоритм, использовавшийся для восстановления регистров путей, поэтому теперь описанного выше ограничения на необходимость поддержки 8.3 путей у раздела больше нет.

Docotic.Pdf: Какие проблемы PVS-Studio обнаружит в зрелом проекте?

+4
Спасибо за статью!

Ложные срабатывания по V3081, V3134 обязательно посмотрим и скорее всего быстро поправим. По поводу же V3125, это известная проблема нашего C# анализатора сейчас — необходимо доработать механизмы dataflow и символьных вычислений, чтобы он смог понимать такие случаи. Здесь наш C# анализатор отстаёт от С/C++ анализатора, который это всё уже умеет. К сожалению, пока руки никак до этого не доходили, но надеемся, что до конца года (или в начале следующего) сможем и по этому направлению что-то сделать.

По поводу проверок возвращаемых значений методов, которые не могут вернуть null — нам уже отписывали подобные замечания\пожелания. Сейчас я склоняюсь к тому, чтобы во многом согласиться с вашими коллегами, которые агитировали за удаление этих избыточных проверок, тем более планируется расширить возможности анализатора диагностировать потенциальные null reference exception, и если контракт у таких методов когда-нибудь поменяется, статический анализатор также поможет вам обнаружить такие потенциальные исключения. Сейчас же я думаю, что мы просто понизим уровень подобных предупреждений, как некритичных.

Короткая заметочка про PVS Studio в CI (и чего не хватает)

+1
Разобрались с этой ситуацией — MSBuild API оказались здесь не при чём — там регистр не теряется, и всё уже делается правильно. Проблема в препроцессоре Visual C++ (cl.exe), который портит пути в препроцессированном файле. Анализатор, соответственно, выдаёт уже такие «испорченные» пути.

Мы попробуем сделать для этой ситуации workaround, попытавшись восстановить путь с помощью ряда WinAPI вызовов (такое уже делается в одной из наших утилит). Надеюсь, получится включить эту правку в предстоящий в октябре релиз.

Короткая заметочка про PVS Studio в CI (и чего не хватает)

0
Вот только про XML весьма жаль: очень уж удобно HTML нужного вида делать из XML. Надеюсь, этот формат когда-нибудь появится в списке «официальных» выходных форматов.

Возможно в более простом виде — в текущем XML слишком много legacy-«мусора» для обратной совместимости, и лишних деталей. Возможно, это будет Json. Наш linux-конвертер уже умеет сохранять подобный более простой формат, но там может не оказаться всего, что вам нужно, т.к. он делался для несколько других целей + на Windows его может быть неудобно использовать с plog'ом.

У нас сейчас, в обозримой перспективе, нет планов отказываться или кардинально менять формат лога MSBuild анализатора, поэтому пока-что можно не переживать по этому поводу )

Короткая заметочка про PVS Studio в CI (и чего не хватает)

+1
Спасибо, что более подробно описали ваш сценарий использования.

На письмо в техподдержку я получил ответ, что такое поведение обусловлено внешним API, но непонятно, почему оно такое избирательное и касается только C++, и не касается C#.

API для разбора C++ и C# проектов достаточно существенно различаются, при этом, т.к. C# анализатор разрабатывался позже, он в целом использует более «новые» API. Для C++ мы также переводили значительную часть функционала на новые API, но некоторый legacy-код ещё остаётся + не для всего новые подходы работают, к сожалению.

Нам потребуется какое-то время, чтобы проверить все места, где регистр может портиться, и понять, насколько эти места остаются критичными (к сожалению, нет просто одного места, где мы «портим» путь). Также, изменение текущего поведения может задеть некоторые другие места, где ожидается как-раз регистро-независимый путь, например, при наложении фильтров на проверяемые файлы или результаты анализа, при запуске анализа на Windows, что потребует дополнительного тестирования.

Я свяжусь с вами, когда ситуация с этим вопросом станет более понятной.

Отчёт — файл с расширением .plog, представляет собой обычный XML-файл. Схема документа встроена, поэтому никаких неожиданностей по выходному формату быть не может. ПО крайней мере пока разработчики схему не поменяют, но не будем рассматривать этот вариант.

На самом деле, мы обычно всё-таки не рекомендуем нашим пользователям завязываться на формат xml отчёта ) Дело в том, что этот формат является представлением сериализованного объекта, завязанного на наш UI и в будущем, особенно в случае потенциальных серьёзных переработок UI компонентов, этот формат может поменяться.

Мы рекомендуем использовать одну из наших утилит для трансформации лога в один из стандартных форматов, таких как csv, html, plain text, и работать уже дальше с ними.

Когда дворецкий — жертва

+1
Ничто не мешало, просто «так получилось» :) Как упоминалось в статье, тестер разрабатывался, когда у нас ещё не было «полноценной» консольной версии анализатора, и для ночных запусков использовался devenv.exe (процесс Visual Studio с плагином нашего анализатора). А т.к. это не консольное приложение, с его unattended запуском было много ньюансов — например какой-то сторонний messagebox мог запросто заблокировать всю ночную сборку. Поэтому и был написан код, который ориентировался на появление на диске файла-лога анализа и считал, что после этого devenv можно по истечению определённого timeout'а «убивать», как зависший.

Когда появился полноценный cmd анализатор, в тестере просто поменяли вызов devenv.exe на PVS-Studio_Cmd.exe, оставив всю эту логику — ведь «всё уже отлажено и работает» :)

Когда дворецкий — жертва

0
Но она ориентирована на выявление проблем другого характера


Теперь в тестере появилась система логгирования и для «убийства» зависших процессов — мы добавили её как раз, когда узнали, что «виноват» SelfTester.

Когда дворецкий — жертва

+5
Суммарно проблема с непонятным «пропаданием» jenkins'а ночью у нас существовала месяцев 8, в какие-то месяцы она практически не проявлялась, а в какие-то повторялась через день. Кстати, как оказалось, эта история ещё не закончена — мы обнаружили, что уже несколько раз процесс java.exe, на котором «висит» Jenkins был убит процессом C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTAgent32.exe. Так что ждите второй части статьи )

Когда дворецкий — жертва

+3
А зачем Jenkins перезапускать каждую ночь?

Jenkins не перезапускается каждую ночь, а только при загрузке системы. Скрипт, про который говорилось в статье, каждые полчаса проверяет, запущен ли jenkins, и перезапускает его, если он по какой-то причине закрылся (или был закрыт), т.к. мы не знали причину, по которой Jenkins закрывался по ночам во время прогона тестов.

Почему нельзя агент запустить и использовать встроенные механизмы запуска Jenkins (scheduled trigger/cron)? Агент оставить как пользовательское приложение. Или я что-то не так поянл


Если вы про master\slave агентов при распределённой сборке, то мы просто не использовали эту архитектуру — у нас один сборочный сервер для Windows и один для Linux и они не связаны (на каждом независимая конфигурация Jenkins), и такой задачи просто не стояло. Но даже бы если мы использовали агентов для распределённой сборки, это ведь, как я понимаю, всё-равно не помешало бы стороннему процессу «убивать» java.exe master'а, как это и происходило у нас.

Время устранять ошибки в Open-Source проектах, конкурс

0
Спасибо за отзыв!

Прогресс работы — можно было сделать внутри обычного окна, зачем-то сделано всплывающее окно.

В каком-то смысле можно сказать, что так «исторически сложилось». Что вы имеете в виду под «обычным окном»? Сейчас прогресс как раз ведь и отображается в обычном окне, но можно было бы сделать его docking окном студии. Либо показывать прогресс в окне выдачи результатов. Текущий вариант также позволяет переключаться на другие задачи, держа в фоне это окошко, чтобы видеть прогресс — для этого его можно «прицепить наверх».

Постоянно спрашивает про лог работы сохранить/нет, вместо того чтобы сохранять с каким-нибудь дефолтным именем. Даже при закрытии студии выводит всплывающее окно. Как минимум это неприятно.

Честно говоря, не думаю, что просто всегда сохранять лог «втихую» будет хорошим решением — для пользователя будет выглядеть так, как будто он потерял лог. А вот сделать в этом диалоге галочку «всегда сохранять в файл по-умолчанию» было бы неплохо — мы подумаем над этим.

Простая ошибка при кодировании — не значит нестрашная ошибка

0
Странно, но VS 2015 Update 3 именно такие проекты и создает (если выбрать ASP.NET Core).

Начиная с VS2017 такой тип проектов использует уже csproj. К сожалению, пользователи ASP.NET Core на VS2015 у нас пока-что выпали из поддержки.

Простая ошибка при кодировании — не значит нестрашная ошибка

+1
Плагин PVS-Studio поддерживает проекты форматов vcxproj\csproj. Касательно ASP.NET, Microsoft отказалась от поддержки json\xproj в последней версии ASP.NET (подробно про это можно почитать здесь). На момент выхода Roslyn 1.0, xproj ещё не поддерживался в Roslyn, а когда мы обновили C# анализатор до Roslyn 2.0, об отказе от поддержки xproj уже стало известно, поэтому мы решили не добавлять поддержки для этого типа проектов. ASP.NET проекты на csproj должны проверяться.

Проблемы, с которыми мы столкнулись при обновлении интерфейса PVS-Studio

+3
Вот здесь вы можете прочитать про различные способы, как это делать. У нас, т.к. используется WinForms, приходится доставать «вручную» цвет для каддого элемента и раскрашивать наши компоненты. Конкретно о том, как это делается у нас, можно прочитать здесь.

Проблемы, с которыми мы столкнулись при обновлении интерфейса PVS-Studio

Ищем и анализируем ошибки в коде GitExtensions

0
Спасибо за замечание, похоже действительно в этом месте анализатор неправильно сработал, постараемся поправить.

Почему вам не следует использовать финализаторы

0
То есть отказ от использования финализаторов проблему не решил.

А использование финализатора решило бы проблему? Нет, оно потенциально только замаскировало бы её. А вот новые ошибки при неправильно написанном финализаторе вполне можно создать.

Почему вам не следует использовать финализаторы

+1
У автора вообще нет ни одного из этих пяти пунктов

Так статья и не ставит своей целью осветить все механизмы освобождения ресурсов
жесткие требования к реализации представлены как «минусы», из-за которых финализаторы писать вроде как не нужно.

А разве жёсткие требования не являются «минусами», раз могут приводить к реальным ошибкам? Статья не призывает вообще их не использовать, но что «нужно десять раз подумать» прежде чем это делать.
Понять, нужен ли финализатор, не просто, а очень просто.

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

По вашему потенциально ошибка, приводящая к неожиданному аварийному завершению приложения не является «неверным способом реализации»?
А больше всего огорчает то, что ресурсы компании прямо сейчас тратятся на защиту чести мундира

Если у вас есть конструктивные предложения, как можно улучшить наш продукт и какие ещё паттерны в реализации деструкторов можно детектировать, мы всегда готовы их выслушать.

Почему вам не следует использовать финализаторы

+1
Согласен с приведённым вами списком. Вот и автор, на мой взгляд, говорит о том, что для большинства ситуаций подходят пункты 3-4, и не стоит сразу лезть в пункт 5 (а вовсе не противопоставляет IDisposable и финализаторы), как и вы сами:
Правда у меня за все время работы такой необходимости не возникло ни разу.


Если же вы взялись делать пункт 5, то
А это от вас зависит.

перечислены разные способы выстрелить себе в ногу.

Почему вам не следует использовать финализаторы

0
Например когда у нас синглтон, который при закрытии приложения должен корректно завершить работу (записать об этом в базу, например), а пользователь жестко убивает процесс. Финализатор в этом случае как правило отрабатывает, диспоз — нет.

Не думаю, что у финализатора больше шансов отработать, чем у dispose'а в случае действительно «жёсткого» завершения работы, например через TerminateProcess. Вот хороший комментарий на эту тему.

Почему вам не следует использовать финализаторы

-1
Т.е. если я реализую свой класс, наследуя его от CriticalFinalizerObject и в нём реализую собственный финализатор, то он будет застрахован от всех проблем, описанных здесь? При этом я не говорю сейчас про использование стандартных классов-наследников CriticalFinalizerObject наподобие того-же SafeHandle, тема статьи именно реализация собственных финализаторов.

Почему вам не следует использовать финализаторы

+1
Статья дает рекомендации на базе заведомо неверной информации.

Как я понимаю, вы про это:
Непосредственно их использовать скорее вредно, чем бесполезно, вот только причина совсем другая:
у наследников CriticalFinalizerObject гарантии выполнения кода завершения лучше, чем у финализатора.

Статья должна была сказать, что использовать финализаторы не нужно, потому что есть CriticalFinalizerObject, и нужно всегда использовать его? А разве CriticalFinalizerObject лишён всех минусов, которые перечислены в статье? Может быть статью стоило назвать тогда «Почему не стоит использовать CriticalFinalizerObject»?

Почему вам не следует использовать финализаторы

0
Финализаторы нужны только для аварийной очистки системных ресурсов, дабы утечки в вашем проекте не поставили в неудобную позу всю машину — об этом ни слова.

Финализаторы не нужны по совсем другой причине — для аварийной очистки есть более надежное место.


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

Непосредственно их использовать скорее вредно, чем бесполезно


Как по вашему это противоречит содержанию статьи?

Проверка исходного кода игрового движка Serious Engine v.1.10 к юбилею шутера Serious Sam

C#, PVS-Studio, ReSharper

0
Спасибо за отзыв! Похоже на ложное срабатывание, мы постараемся поправить.

Новогодний релиз PVS-Studio 6.00: проверяем Roslyn

0
Отпишите, пожалуйста, баг на support@viva64.com, мы попробуем разобраться.

Первый вздох PVS-Studio для C#

0
Проекты добавлены в sln файле через относительные пути? В первых версиях PVS-Studio C# была проблема с тем, что не проверялись проекты, заданные через относительные пути. Попробуйте проверить в последней версии, доступной на files.viva64.com/beta/PVS-Studio_setup.exe.

Первый вздох PVS-Studio для C#

0
Возможно, вы не сохранили файл solution'а? PVS-Studio читает этот файл независимо от студии.

Для отключения предупреждений — меню PVS-Studio|Options...|Detectable Errors (C#).

Экспериментальная версия PVS-Studio, поддерживающая C#

0
В появляющемся окошке (при проверке одного проекта) указывается какое-то количество файлов?

Может быть файлы в проекты включены не как цели для компиляции (можно посмотреть в свойствах файла)? Также отдельные участки кода не будут проверены, если они заключены в define'ы, не определённые для проверяемого проекта.

Если возможно, пришлите пожалуйста csproj файл на support@viva64.com, мы попробуем разобраться.

Экспериментальная версия PVS-Studio, поддерживающая C#

0
Что пишется, когда пытаетесь проверить один файл? А если проверить один проект (через контекстное меню в Solution Explorer)? Solution включает обычные csproj проекты?

Также можно попробовать проверить solution напрямую из командной строки с помощью PVS-Studio_Cs.exe, возможно проблема на стороне Visual Studio плагина.

Экспериментальная версия PVS-Studio, поддерживающая C#

0
Проверьте, пожалуйста, какую платформу\конфигурацию вы проверяете. Если для какой-либо конфигурации сборка проекта отключена, то PVS-Studio не будет проверять такой проект.

Экспериментальная версия PVS-Studio, поддерживающая C#

0
В статье имелось в виду, что мы мигрируем для C# самые простые General Analysis проверки C++ версии PVS-Studio, у нас нет в планах дублировать проверки каких-либо других анализаторов. Безусловно, неизбежно пересечение наших диагностик и диагностик других анализаторов, но это не означает, что они идентичны.

Экспериментальная версия PVS-Studio, поддерживающая C#

0
Пришлите пожалуйста тестовый проект, на котором повторяется ошибка на support@viva64.com, мы посмотрим, что можно сделать.

Экспериментальная версия PVS-Studio, поддерживающая C#

0
Да, действительно есть такой нюанс, мы посмотрим, что можно с этим сделать. Пока что вы можете прислать просто plog, там все Fail будут видны. Его можно получить через команду меню PVS-Studio|Open/Save|Save Analysis Report As
1 There