Ну во первых, наш продукт нельзя назвать чисто «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-битность инсталятора не создаёт для нас или наших пользователей каких-либо проблем, поэтому мы не видим это критичной задачей.
Но для того, чтобы это всё работало, необходима поддержка коротких путей как минимум на том диске, где ведётся анализ. Для этого в реестре по пути 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 путей у раздела больше нет.
Ложные срабатывания по V3081, V3134 обязательно посмотрим и скорее всего быстро поправим. По поводу же V3125, это известная проблема нашего C# анализатора сейчас — необходимо доработать механизмы dataflow и символьных вычислений, чтобы он смог понимать такие случаи. Здесь наш C# анализатор отстаёт от С/C++ анализатора, который это всё уже умеет. К сожалению, пока руки никак до этого не доходили, но надеемся, что до конца года (или в начале следующего) сможем и по этому направлению что-то сделать.
По поводу проверок возвращаемых значений методов, которые не могут вернуть null — нам уже отписывали подобные замечания\пожелания. Сейчас я склоняюсь к тому, чтобы во многом согласиться с вашими коллегами, которые агитировали за удаление этих избыточных проверок, тем более планируется расширить возможности анализатора диагностировать потенциальные null reference exception, и если контракт у таких методов когда-нибудь поменяется, статический анализатор также поможет вам обнаружить такие потенциальные исключения. Сейчас же я думаю, что мы просто понизим уровень подобных предупреждений, как некритичных.
Разобрались с этой ситуацией — MSBuild API оказались здесь не при чём — там регистр не теряется, и всё уже делается правильно. Проблема в препроцессоре Visual C++ (cl.exe), который портит пути в препроцессированном файле. Анализатор, соответственно, выдаёт уже такие «испорченные» пути.
Мы попробуем сделать для этой ситуации workaround, попытавшись восстановить путь с помощью ряда WinAPI вызовов (такое уже делается в одной из наших утилит). Надеюсь, получится включить эту правку в предстоящий в октябре релиз.
Вот только про XML весьма жаль: очень уж удобно HTML нужного вида делать из XML. Надеюсь, этот формат когда-нибудь появится в списке «официальных» выходных форматов.
Возможно в более простом виде — в текущем XML слишком много legacy-«мусора» для обратной совместимости, и лишних деталей. Возможно, это будет Json. Наш linux-конвертер уже умеет сохранять подобный более простой формат, но там может не оказаться всего, что вам нужно, т.к. он делался для несколько других целей + на Windows его может быть неудобно использовать с plog'ом.
У нас сейчас, в обозримой перспективе, нет планов отказываться или кардинально менять формат лога MSBuild анализатора, поэтому пока-что можно не переживать по этому поводу )
Спасибо, что более подробно описали ваш сценарий использования.
На письмо в техподдержку я получил ответ, что такое поведение обусловлено внешним API, но непонятно, почему оно такое избирательное и касается только C++, и не касается C#.
API для разбора C++ и C# проектов достаточно существенно различаются, при этом, т.к. C# анализатор разрабатывался позже, он в целом использует более «новые» API. Для C++ мы также переводили значительную часть функционала на новые API, но некоторый legacy-код ещё остаётся + не для всего новые подходы работают, к сожалению.
Нам потребуется какое-то время, чтобы проверить все места, где регистр может портиться, и понять, насколько эти места остаются критичными (к сожалению, нет просто одного места, где мы «портим» путь). Также, изменение текущего поведения может задеть некоторые другие места, где ожидается как-раз регистро-независимый путь, например, при наложении фильтров на проверяемые файлы или результаты анализа, при запуске анализа на Windows, что потребует дополнительного тестирования.
Я свяжусь с вами, когда ситуация с этим вопросом станет более понятной.
Отчёт — файл с расширением .plog, представляет собой обычный XML-файл. Схема документа встроена, поэтому никаких неожиданностей по выходному формату быть не может. ПО крайней мере пока разработчики схему не поменяют, но не будем рассматривать этот вариант.
На самом деле, мы обычно всё-таки не рекомендуем нашим пользователям завязываться на формат xml отчёта ) Дело в том, что этот формат является представлением сериализованного объекта, завязанного на наш UI и в будущем, особенно в случае потенциальных серьёзных переработок UI компонентов, этот формат может поменяться.
Мы рекомендуем использовать одну из наших утилит для трансформации лога в один из стандартных форматов, таких как csv, html, plain text, и работать уже дальше с ними.
Ничто не мешало, просто «так получилось» :) Как упоминалось в статье, тестер разрабатывался, когда у нас ещё не было «полноценной» консольной версии анализатора, и для ночных запусков использовался devenv.exe (процесс Visual Studio с плагином нашего анализатора). А т.к. это не консольное приложение, с его unattended запуском было много ньюансов — например какой-то сторонний messagebox мог запросто заблокировать всю ночную сборку. Поэтому и был написан код, который ориентировался на появление на диске файла-лога анализа и считал, что после этого devenv можно по истечению определённого timeout'а «убивать», как зависший.
Когда появился полноценный cmd анализатор, в тестере просто поменяли вызов devenv.exe на PVS-Studio_Cmd.exe, оставив всю эту логику — ведь «всё уже отлажено и работает» :)
Суммарно проблема с непонятным «пропаданием» jenkins'а ночью у нас существовала месяцев 8, в какие-то месяцы она практически не проявлялась, а в какие-то повторялась через день. Кстати, как оказалось, эта история ещё не закончена — мы обнаружили, что уже несколько раз процесс java.exe, на котором «висит» Jenkins был убит процессом C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTAgent32.exe. Так что ждите второй части статьи )
Jenkins не перезапускается каждую ночь, а только при загрузке системы. Скрипт, про который говорилось в статье, каждые полчаса проверяет, запущен ли jenkins, и перезапускает его, если он по какой-то причине закрылся (или был закрыт), т.к. мы не знали причину, по которой Jenkins закрывался по ночам во время прогона тестов.
Почему нельзя агент запустить и использовать встроенные механизмы запуска Jenkins (scheduled trigger/cron)? Агент оставить как пользовательское приложение. Или я что-то не так поянл
Если вы про master\slave агентов при распределённой сборке, то мы просто не использовали эту архитектуру — у нас один сборочный сервер для Windows и один для Linux и они не связаны (на каждом независимая конфигурация Jenkins), и такой задачи просто не стояло. Но даже бы если мы использовали агентов для распределённой сборки, это ведь, как я понимаю, всё-равно не помешало бы стороннему процессу «убивать» java.exe master'а, как это и происходило у нас.
Прогресс работы — можно было сделать внутри обычного окна, зачем-то сделано всплывающее окно.
В каком-то смысле можно сказать, что так «исторически сложилось». Что вы имеете в виду под «обычным окном»? Сейчас прогресс как раз ведь и отображается в обычном окне, но можно было бы сделать его docking окном студии. Либо показывать прогресс в окне выдачи результатов. Текущий вариант также позволяет переключаться на другие задачи, держа в фоне это окошко, чтобы видеть прогресс — для этого его можно «прицепить наверх».
Постоянно спрашивает про лог работы сохранить/нет, вместо того чтобы сохранять с каким-нибудь дефолтным именем. Даже при закрытии студии выводит всплывающее окно. Как минимум это неприятно.
Честно говоря, не думаю, что просто всегда сохранять лог «втихую» будет хорошим решением — для пользователя будет выглядеть так, как будто он потерял лог. А вот сделать в этом диалоге галочку «всегда сохранять в файл по-умолчанию» было бы неплохо — мы подумаем над этим.
Плагин PVS-Studio поддерживает проекты форматов vcxproj\csproj. Касательно ASP.NET, Microsoft отказалась от поддержки json\xproj в последней версии ASP.NET (подробно про это можно почитать здесь). На момент выхода Roslyn 1.0, xproj ещё не поддерживался в Roslyn, а когда мы обновили C# анализатор до Roslyn 2.0, об отказе от поддержки xproj уже стало известно, поэтому мы решили не добавлять поддержки для этого типа проектов. ASP.NET проекты на csproj должны проверяться.
Вот здесь вы можете прочитать про различные способы, как это делать. У нас, т.к. используется WinForms, приходится доставать «вручную» цвет для каддого элемента и раскрашивать наши компоненты. Конкретно о том, как это делается у нас, можно прочитать здесь.
То есть отказ от использования финализаторов проблему не решил.
А использование финализатора решило бы проблему? Нет, оно потенциально только замаскировало бы её. А вот новые ошибки при неправильно написанном финализаторе вполне можно создать.
У автора вообще нет ни одного из этих пяти пунктов
Так статья и не ставит своей целью осветить все механизмы освобождения ресурсов
жесткие требования к реализации представлены как «минусы», из-за которых финализаторы писать вроде как не нужно.
А разве жёсткие требования не являются «минусами», раз могут приводить к реальным ошибкам? Статья не призывает вообще их не использовать, но что «нужно десять раз подумать» прежде чем это делать.
Понять, нужен ли финализатор, не просто, а очень просто.
Может быть для вас это и так, а на мой взгляд принять решение использовать что-то или нет — это ключевой момент, и перечисленные минусы ещё раз должны напомнить важность этого.
Ну и рекламируемый инструмент статического анализа вместо предупреждения о неверном способе реализации завершающего кода дает подсказки про NRE в финализаторах, которые вообще нет смысла писать.
По вашему потенциально ошибка, приводящая к неожиданному аварийному завершению приложения не является «неверным способом реализации»?
А больше всего огорчает то, что ресурсы компании прямо сейчас тратятся на защиту чести мундира
Если у вас есть конструктивные предложения, как можно улучшить наш продукт и какие ещё паттерны в реализации деструкторов можно детектировать, мы всегда готовы их выслушать.
Согласен с приведённым вами списком. Вот и автор, на мой взгляд, говорит о том, что для большинства ситуаций подходят пункты 3-4, и не стоит сразу лезть в пункт 5 (а вовсе не противопоставляет IDisposable и финализаторы), как и вы сами:
Правда у меня за все время работы такой необходимости не возникло ни разу.
Если же вы взялись делать пункт 5, то
А это от вас зависит.
перечислены разные способы выстрелить себе в ногу.
Например когда у нас синглтон, который при закрытии приложения должен корректно завершить работу (записать об этом в базу, например), а пользователь жестко убивает процесс. Финализатор в этом случае как правило отрабатывает, диспоз — нет.
Не думаю, что у финализатора больше шансов отработать, чем у dispose'а в случае действительно «жёсткого» завершения работы, например через TerminateProcess. Вот хороший комментарий на эту тему.
Во вторых, в папку Program Files (x86) он ставится, т.к. сам наш Windows инсталятор является 32-битным — можно сказать, что так исторически сложилось. В более старых версиях PVS-Studio, когда мы поддерживали старые IDE, такие как, например, Visual Studio 2008, возможно (я точно не ручаюсь, т.к. уже не помню), установка плагинов к таким IDE накладывала ограничения на создание чисто-64битного установщика. Также, PVS-Studio можно было установить и на 32-битную версию Windows (как я писал выше, сейчас это уже не актуально).
Так что, резюмируя, сам инсталятор, скорее всего, уже можно сделать 64-битным (возможно, мы это сделаем в будущем), однако на данный момент 32-битность инсталятора не создаёт для нас или наших пользователей каких-либо проблем, поэтому мы не видим это критичной задачей.
В релизе 6.26 мы поменяли алгоритм, использовавшийся для восстановления регистров путей, поэтому теперь описанного выше ограничения на необходимость поддержки 8.3 путей у раздела больше нет.
Ложные срабатывания по V3081, V3134 обязательно посмотрим и скорее всего быстро поправим. По поводу же V3125, это известная проблема нашего C# анализатора сейчас — необходимо доработать механизмы dataflow и символьных вычислений, чтобы он смог понимать такие случаи. Здесь наш C# анализатор отстаёт от С/C++ анализатора, который это всё уже умеет. К сожалению, пока руки никак до этого не доходили, но надеемся, что до конца года (или в начале следующего) сможем и по этому направлению что-то сделать.
По поводу проверок возвращаемых значений методов, которые не могут вернуть null — нам уже отписывали подобные замечания\пожелания. Сейчас я склоняюсь к тому, чтобы во многом согласиться с вашими коллегами, которые агитировали за удаление этих избыточных проверок, тем более планируется расширить возможности анализатора диагностировать потенциальные null reference exception, и если контракт у таких методов когда-нибудь поменяется, статический анализатор также поможет вам обнаружить такие потенциальные исключения. Сейчас же я думаю, что мы просто понизим уровень подобных предупреждений, как некритичных.
Мы попробуем сделать для этой ситуации workaround, попытавшись восстановить путь с помощью ряда WinAPI вызовов (такое уже делается в одной из наших утилит). Надеюсь, получится включить эту правку в предстоящий в октябре релиз.
Возможно в более простом виде — в текущем XML слишком много legacy-«мусора» для обратной совместимости, и лишних деталей. Возможно, это будет Json. Наш linux-конвертер уже умеет сохранять подобный более простой формат, но там может не оказаться всего, что вам нужно, т.к. он делался для несколько других целей + на Windows его может быть неудобно использовать с plog'ом.
У нас сейчас, в обозримой перспективе, нет планов отказываться или кардинально менять формат лога MSBuild анализатора, поэтому пока-что можно не переживать по этому поводу )
API для разбора C++ и C# проектов достаточно существенно различаются, при этом, т.к. C# анализатор разрабатывался позже, он в целом использует более «новые» API. Для C++ мы также переводили значительную часть функционала на новые API, но некоторый legacy-код ещё остаётся + не для всего новые подходы работают, к сожалению.
Нам потребуется какое-то время, чтобы проверить все места, где регистр может портиться, и понять, насколько эти места остаются критичными (к сожалению, нет просто одного места, где мы «портим» путь). Также, изменение текущего поведения может задеть некоторые другие места, где ожидается как-раз регистро-независимый путь, например, при наложении фильтров на проверяемые файлы или результаты анализа, при запуске анализа на Windows, что потребует дополнительного тестирования.
Я свяжусь с вами, когда ситуация с этим вопросом станет более понятной.
На самом деле, мы обычно всё-таки не рекомендуем нашим пользователям завязываться на формат xml отчёта ) Дело в том, что этот формат является представлением сериализованного объекта, завязанного на наш UI и в будущем, особенно в случае потенциальных серьёзных переработок UI компонентов, этот формат может поменяться.
Мы рекомендуем использовать одну из наших утилит для трансформации лога в один из стандартных форматов, таких как csv, html, plain text, и работать уже дальше с ними.
Когда появился полноценный cmd анализатор, в тестере просто поменяли вызов devenv.exe на PVS-Studio_Cmd.exe, оставив всю эту логику — ведь «всё уже отлажено и работает» :)
Теперь в тестере появилась система логгирования и для «убийства» зависших процессов — мы добавили её как раз, когда узнали, что «виноват» SelfTester.
Jenkins не перезапускается каждую ночь, а только при загрузке системы. Скрипт, про который говорилось в статье, каждые полчаса проверяет, запущен ли jenkins, и перезапускает его, если он по какой-то причине закрылся (или был закрыт), т.к. мы не знали причину, по которой Jenkins закрывался по ночам во время прогона тестов.
Если вы про master\slave агентов при распределённой сборке, то мы просто не использовали эту архитектуру — у нас один сборочный сервер для Windows и один для Linux и они не связаны (на каждом независимая конфигурация Jenkins), и такой задачи просто не стояло. Но даже бы если мы использовали агентов для распределённой сборки, это ведь, как я понимаю, всё-равно не помешало бы стороннему процессу «убивать» java.exe master'а, как это и происходило у нас.
В каком-то смысле можно сказать, что так «исторически сложилось». Что вы имеете в виду под «обычным окном»? Сейчас прогресс как раз ведь и отображается в обычном окне, но можно было бы сделать его docking окном студии. Либо показывать прогресс в окне выдачи результатов. Текущий вариант также позволяет переключаться на другие задачи, держа в фоне это окошко, чтобы видеть прогресс — для этого его можно «прицепить наверх».
Честно говоря, не думаю, что просто всегда сохранять лог «втихую» будет хорошим решением — для пользователя будет выглядеть так, как будто он потерял лог. А вот сделать в этом диалоге галочку «всегда сохранять в файл по-умолчанию» было бы неплохо — мы подумаем над этим.
Начиная с VS2017 такой тип проектов использует уже csproj. К сожалению, пользователи ASP.NET Core на VS2015 у нас пока-что выпали из поддержки.
А использование финализатора решило бы проблему? Нет, оно потенциально только замаскировало бы её. А вот новые ошибки при неправильно написанном финализаторе вполне можно создать.
Так статья и не ставит своей целью осветить все механизмы освобождения ресурсов
А разве жёсткие требования не являются «минусами», раз могут приводить к реальным ошибкам? Статья не призывает вообще их не использовать, но что «нужно десять раз подумать» прежде чем это делать.
Может быть для вас это и так, а на мой взгляд принять решение использовать что-то или нет — это ключевой момент, и перечисленные минусы ещё раз должны напомнить важность этого.
По вашему потенциально ошибка, приводящая к неожиданному аварийному завершению приложения не является «неверным способом реализации»?
Если у вас есть конструктивные предложения, как можно улучшить наш продукт и какие ещё паттерны в реализации деструкторов можно детектировать, мы всегда готовы их выслушать.
Если же вы взялись делать пункт 5, то
перечислены разные способы выстрелить себе в ногу.
Не думаю, что у финализатора больше шансов отработать, чем у dispose'а в случае действительно «жёсткого» завершения работы, например через TerminateProcess. Вот хороший комментарий на эту тему.