Как мы пытаемся продать PVS-Studio в Google или очередные ошибки в Chromium

    PVS-Studio интегрируется в Ninja для проверки Chomium.


    Когда мы пишем статьи про проверки каких-либо проектов с помощью PVS-Studio, то, как правило, у нас прибавляется клиентов. Тут все честно. Программисты не любят рекламу, но охотно отзываются на интересные материалы, которые легко проверить. Поэтому мы не рекламируем свой инструмент, а просто показываем, что он умеет. Однако, хотя мы проверили код Chromium уже три раза и трижды находили в нем ошибки, ордера с почтой в google.com в моей почте до сих пор нет. Поскольку мне интересно, что я делаю не так, и почему Google пока не использует PVS-Studio, я решил написать очередную статью.

    Эта статья состоит из двух частей. В первой рассказывается об инфраструктуре проекта Chromium и нюансах интеграции, во второй приведены очередные найденные ошибки.

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

    Хотите узнать, почему разрабатывать Chromium сложно и далеко не каждый инструмент для программистов может быть использован в проекте Chromium? Тогда читаем…



    Разработчики Chromium не любят Visual Studio, не используют Makefile, но при этом у них фантастически качественный код. Как же так?


    Разработка проектов типа Chromium чрезвычайно сложна. На самом деле, мне даже немного неловко писать «проектов типа Chromium», так как других проектов подобного уровня я не знаю. Нет, понятно, что есть ядро Linux, есть среда Visual Studio и много еще больших и крупных проектов. Но лично мне довелось пока «постоять рядом» только с Chromium. И то, что я видел – очень интересно любому программисту, так как там есть чему поучиться.

    Например, при разработке Chromium не очень-то активно, оказывается, используют Visual Studio. Причина проста – Chromium содержит огромное количество проектов, и IDE от Microsoft откровенно говоря «не тянет» такое количество. «Ага!» — сказали суровые линуксоиды… «Еще бы!!!» Но при разработке Chromium не используют и линуксовые Makefile. Ровно по той же самой причине – стандартный GNU make «не тянет» такое количество проектов и работает слишком долго.

    Что же используют разработчики Chromium? Это сборочная система GYP (Generate Your Projects). С ее помощью можно генерировать либо файлы .vcxproj (MSBuild/Visual C++), либо файлы системы Ninja (это такой сильно упрощенный и быстрый makefile). Поэтому для того, чтобы регулярно использовать какой-нибудь статический анализ, надо интегрировать его именно в эту сборочную систему. Чем мы и занялись для того, чтобы продать PVS-Studio в Google.

    Проект Chromium примечателен тем, что размер его исходного кода на языках C/C++, учитывая сторонние библиотеки (англ. third party library), превышает 500МБ, а каждое изменение кода проверяется десятками тысяч автоматических тестов параллельно на сотнях тестовых компьютеров различных архитектур и конфигураций. Можно отметить и высокую скорость разработки в данном проекте: в 2012-м году в репозиторий Chromium было создано более 48 тысяч ревизий более чем 900 уникальными авторами, что соответствует в среднем одной ревизии каждые 11 минут и одной ревизии в неделю от каждого активного участника проекта.

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

    Хотя PVS-Studio и не является open source проектом, в гибкости нам не откажешь. Поэтому мы захотели показать на примере Chromium, что можем встроиться в его сборочную систему и проверять такой большой проект без проблем.

    Как встроить PVS-Studio в сборочную систему Chromium для регулярных проверок?



    Общие сведения о принципах работы PVS-Studio


    В дистрибутиве PVS-Studio можно выделить 2 главных компонента: command-line анализатор PVS-Studio.exe и IDE плагин, интегрирующий этот command-line анализатор в одну из поддерживаемых сред разработки (Microsoft Visual Studio и Embarcadero RAD Studio).

    Command-line анализатор по принципу своей работы очень схож с компилятором — он вызывается для каждого из проверяемых файлов с параметрами, включающими в себя, в том числе, и оригинальные параметры компиляции этого файла. Затем анализатор вызывает необходимый ему внешний препроцессор (в соответствии с компилятором, используемым при сборке проверяемого файла) и производит непосредственный анализ полученного препроцессированного временного файла (i-файла), т.е. файла, в котором раскрыты все include и define директивы.

    Но использование анализатора PVS-Studio.exe не ограничивается IDE плагинами. Как уже было сказано выше, command-line анализатор, очень близок в своём использовании непосредственно к компилятору. Соответственно, его вызов можно встроить, при необходимости, и напрямую в сборочную систему, наравне с самим компилятором. Например, если ваш проект собирается в IDE Eclipse с помощью gcc, вы можете встроить проверку PVS-Studio в ваши makefile'ы.

    Для прямой интеграции статического анализа в сборочный процесс необходимо встроить вызов PVS-Studio.exe в сборочный сценарий рядом с непосредственным вызовом самого компилятора C/C++, и передать анализатору те же параметры, что передаются компилятору (а также несколько дополнительных параметров, контролирующих вывод результатов анализа). Это требование обусловлено тем, что статический анализатор необходимо будет запустить для каждого проверяемого файла, с соответствующими этому файлу специфичными параметрами. А это удобнее всего сделать как раз в том месте, где и происходит автоматический обход всех исходных файлов проекта.

    Проверка проекта Chromium статическим анализатором PVS-Studio.exe


    Как написано выше, Chromium разрабатывается с помощью сборочной системы GYP (Generate Your Projects), позволяющей получить нативные проектные файлы для различных ОС и компиляторов. Т.к. на данный момент анализатор PVS-Studio поддерживает только ОС Windows, рассмотрим возможные варианты сборки Chromium с помощью компилятора Visual C++ 10. Данный компилятор (cl.exe) поставляется в составе интегрированной среды разработки Visual Studio, а также может быть установлен отдельно из бесплатного пакета Windows SDK.

    Использование проектных файлов MSBuild


    Используемая в Chromium система GYP позволяет получить проектные файлы MSBuild (vcxproj) для сборки Chromium с помощью компилятора Visual C++ (cl.exe). Сборочная система MSBuild является частью пакета .NET Framework, являющегося одним из стандартных компонентов ОС семейства Windows.

    Наиболее простым способом проверки проекта Chromium анализатором PVS-Studio будет использование «родного» для него IDE плагина среды Visual Studio. Проектные файлы MSBuild можно открыть для проверки в среде разработки Visual Studio. При этом IDE плагин PVS-Studio автоматически соберёт всю необходимую информацию о каждом из файлов проекта и запустит для них статический анализатор PVS-Studio.exe. Заметим, что бесплатная версия среды разработки Visual Studio Express Edition не поддерживает работу с IDE плагинами.

    Сборку и проверку проектных файлов vcxproj можно также произвести напрямую, без использования среды Visual Studio, с помощью сборочной системы MSBuild (а точнее, используя command-line утилиту MSBuild.exe). Для проверки проектов статическим анализатором в таком режиме необходимо будет напрямую интегрировать в каждый проектный файл вызов command-line анализатора PVS-Studio.exe (можно также и импортировать во все проектные файлы общий props файл, содержащий подобный вызов анализатора).

    Стоит заметить, что хотя MSBuild и позволяет напрямую из своих сборочных скриптов (которыми, в том числе, и являются проектные файлы vcxproj) вызывать исполняемые файлы, вызов таких сборочных инструментов, как компилятор и компоновщик в стандартных проектах осуществляется с помощью специальных подключаемых модулей-обёрток (называемых в терминологии MSBuild сборочными задачами – Build Tasks). Дистрибутив PVS-Studio содержит подобный модуль сборочной задачи для сценариев MSBuild, а также использующий его Props (property sheet) файл, который можно напрямую импортировать в стандартные проекты vcxproj для интеграции в них статического анализа.

    Использование проектных файлов Ninja


    Сборка Chromium под Windows с помощью компилятора cl.exe возможна и с помощью скриптов сборочной системы Ninja, которые также можно получить генератором проектов GYP.

    Как было описано выше, для прямой интеграции статического анализа PVS-Studio в сборочный процесс необходимо встроить вызов PVS-Studio.exe в том месте, где происходит обход исходных файлов сборочной системой при их компиляции.

    В случае с файлами системы Ninja подобный способ интеграции оказывается затруднённым тем, что собираемые файлы жёстко прописываются в авто-сгенерированных файлах *.ninja как зависимости для obj файлов. В связи с этим, для интеграции анализа на данном шаге сборки необходимо будет модифицировать соответствующие этому шагу правила сборки (описанные в общем файле build.ninja): это сс и cxx, т.к. именно эти правила используются при обходе всех исходных файлов.

    На данный момент нам не удалось напрямую добавить в правила cc и cxx вызов PVS-Studio.exe. Правила сборки системы Ninja позволяют использовать для определения команды к выполнению только одну переменную command. При этом, в соответствии с документацией, переменная command может содержать и несколько команд, разделённых символами &&.Однако, если добавить к существующему правилу, как например:
    command = ninja -t msvc -e $arch -- $cc /nologo /showIncludes /FC 
    @$out.rsp /c $in /Fo$out /Fd$pdbname

    вызов PVS-Studio.exe:
    PVS = "PVS-Studio.exe"
    ...
    command = ninja -t msvc -e $arch -- $cc /nologo /showIncludes /FC 
    @$out.rsp /c $in /Fo$out /Fd$pdbname && $PVS –cfg "c:\test.cfg"

    то такой вызов воспринимается, как часть аргументов для процесса ninja, и, соответственно, передаётся при вызове –t msvs как аргумент в cl.exe ($cc). Аналогично, если поместить вызов $PVS в начало строки, то остальные параметры после && передаются в качестве аргументов уже в PVS-Studio.exe.

    Конечно, для обхода данного ограничения можно написать программу-обёртку, которая по очереди сначала вызовет ninja, а затем PVS-Studio.exe, и прописать вызов этой обёртки в начало переменной command для интересующих нас сборочных правил (cc и cxx). Это мы и сделали для того, чтобы проверить Chromium с помощью PVS-Studio таким образом.

    Особенности использования Command-line анализатора PVS-Studio.exe при прямой интеграции статического анализа в сценарии сборочной системы.


    Главное, что необходимо помнить при использовании PVS-Studio.exe в режиме прямой интеграции со сборочной системой (т.е. без IDE плагина) — это необходимость произвести препроцессирование каждого проверяемого исходного файла перед непосредственным выполнением анализа. PVS-Studio.exe должен в качестве одного из параметров своего запуска получить флаг cl-params, после которого необходимо передать все «оригинальные» параметры компиляции данного файла. PVS-Studio.exe сам запустит внешний препроцессор (например, cl.exe), добавив к данным параметрам флаги, управляющие препроцессором (флаг /P в случае cl.exe).

    Однако, из-за различий в поведении препроцессора и компилятора возможна и ситуация, в которой флагов компиляции может оказаться недостаточно для корректного препроцесирования исходного C/C++ файла. В частности, препроцессирование может оказаться невозможным, если в переданных препроцессору include путях отсутствует путь до директории, содержащей заголовочный файл, используемый как precompiled заголовок. В такой ситуации компиляция будет проходить успешно (конечно, если уже был сгенерирован указанный компилятору pch файл), но препроцессор будет завершать работу с ошибкой «cannot open include file».

    IDE плагин PVS-Studio для разрешения данной проблемы в случае использования в файле precompiled заголовка сканирует все файлы проекта, содержащего проверяемый файл, и добавляет в include пути директорию файла, используемого для генерации требуемого pch (которых в проекте может быть и несколько). Для корректной же работы PVS-Studio.exe в режиме прямой интеграции необходимо обеспечить корректность работы препроцессора, также передавая этот путь в числе других параметров компиляции. Это можно сделать, добавив в перечень передаваемых анализатору аргументов компилятора ещё один –I (/I) параметр с соответствующей директорией.

    Проект Chromium содержит несколько сотен подобных файлов, т.е. файлов, использующих precompiled заголовки, к которым при их компиляции в Includes не передаётся путь до папки, содержащей сами h файлы, из которых эти заголовки были получены. Для корректной проверки этих файлов анализатором PVS-Studio в режиме прямой интеграции (т.е. без использования плагина) необходимо модифицировать сборочную систему описанным выше образом перед запуском анализа.

    Но можно поступить проще. Например, мы просто отключили precompiled headers при сборке Chromium для интеграции PVS-Studio в сборочную систему.

    Что делать с полученным в результате интеграции логом проверки?


    В результате такой интеграции будет получен отчет в так называемом «сыром» (raw) виде. Его можно открыть в нашей же утилите PVS-Studio Standalone (про которую я писал здесь). И начать работать в полноценной среде с навигацией и прочими удобствами.

    Резюме по интеграции PVS-Studio в сборочную систему Chromium


    Итак, как же выглядит интеграция PVS-Studio в сборочную систему Chromium?
    1. Отключаем precompiled headers.
    2. Генерируем проекты Ninja.
    3. В проектах Ninja вызывается специальная утилита PVS-Studio Wrapper (не идет в дистрибутиве PVS-Studio), которая уже вызывает PVS-Studio.
    4. Результат проверки – сырой лог – открываем с помощью PVS-Studio Standalone и работаем с найденными ошибками.
    А теперь переходим ко второй части статьи – примерам обнаруженных ошибок.

    Примеры обнаруженных ошибок


    Целью очередной проверки Chromium был не поиск ошибок, а осваивание новой системы сборки. Точнее встраивание PVS-Studio в нее. Поэтому Андрей Карпов просмотрел диагностические сообщения очень и очень поверхностно. Тем не менее, он всё равно кое-что углядел и прислал мне несколько фрагментов кода, снабдив их комментариями. То, что даже быстрый просмотр позволяет найти ошибки не удивительно для проектов такого размера как Chromium. Как бы они не были хорошо написаны, в них всегда есть ошибки. Тем более проект Chromium быстро развивается и обрастает новыми функциями и библиотеками.

    Ошибки в большинстве своём относятся к сторонним библиотекам. Впрочем, от этого они не перестают быть ошибками. Поскольку, авторы Chromium очень активно развивают библиотеки, из которых строится проект, мы думаем, им будет интересно посмотреть, что смог найти в них анализатор PVS-Studio.

    Да, хочется напомнить, что это далеко не первая проверка Chromium:Именно поэтому, сложно убедить Андрея уделить просмотру ошибок больше времени. Во-первых, уже не так интересно. Во-вторых, полноценно проанализировать отчёт могут только разработчики Chromium. Делать анализ в одиночку, тем более, не будучи знакомым с проектом и библиотеками, неподъемный труд. Да и вообще, проект можно (и нужно) проверять каждый день, а не раз в полгода. Но это уже на совести сообщества, которое работает над развитием проекта Chromium и отдельных библиотек.

    Не там поставленная скобка (параноики, могут усмотреть в этом закладку :)


    static SECStatus
    ssl3_SendEncryptedExtensions(sslSocket *ss)
    {
      static const unsigned char P256_SPKI_PREFIX[] = {
        0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2a, 0x86,
        0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x08, 0x2a,
        0x86, 0x48, 0xce, 0x3d, 0x03, 0x01, 0x07, 0x03,
        0x42, 0x00, 0x04
      };
      ....
      if (.... ||
          memcmp(spki->data, P256_SPKI_PREFIX,
                 sizeof(P256_SPKI_PREFIX) != 0))
      {
        PORT_SetError(SSL_ERROR_INVALID_CHANNEL_ID_KEY);
        rv = SECFailure;
        goto loser;
      }
      ....
    }

    Предупреждение PVS-Studio (библиотека Network Security Services): V526 The 'memcmp' function returns 0 if corresponding buffers are equal. Consider examining the condition for mistakes. ssl3con.c 10533

    Из-за неправильно поставленной скобки функция memcmp() сравнивает один байт.

    Выражение «sizeof(P256_SPKI_PREFIX) != 0» всегда истинно. То-есть значение этого выражения равно 1.

    Правильная проверка должна быть такой:
    if (.... ||
        memcmp(spki->data, P256_SPKI_PREFIX,
               sizeof(P256_SPKI_PREFIX)) != 0)

    Переменая 'i' похожа на 1.


    void SkCanvasStack::pushCanvas(....) {
      ....
      for (int i = fList.count() - 1; i > 0; --i) {
        SkIRect localBounds = canvasBounds;
        localBounds.offset(origin - fCanvasData[i-1].origin);
    
        fCanvasData[i-1].requiredClip.op(localBounds,
                                         SkRegion::kDifference_Op);
        fList[i-i]->clipRegion(fCanvasData[i-1].requiredClip);
      }
      ....
    }

    Слабо заметить подозрительное? :) Анализатору нет.

    Предупреждение PVS-Studio (библиотека Skia Graphics Engine): V501 There are identical sub-expressions to the left and to the right of the '-' operator: i — i SkCanvasStack.cpp 38

    В качестве индекса несколько раз используется выражение [i — 1]. А в одном месте, написано [i-i]. Это очень похоже на опечатку. Скорее всего, здесь тоже должна вычитаться единица.

    «Одноразовый» цикл


    Code* Code::FindFirstCode() {
      ASSERT(is_inline_cache_stub());
      DisallowHeapAllocation no_allocation;
      int mask = RelocInfo::ModeMask(RelocInfo::CODE_TARGET);
      for (RelocIterator it(this, mask); !it.done(); it.next())
      {
        RelocInfo* info = it.rinfo();
        return
          Code::GetCodeFromTargetAddress(info->target_address());
      }
      return NULL;
    }

    Предупреждение PVS-Studio (Chromium): V612 An unconditional 'return' within a loop. objects.cc 10326

    Цикл будет завершен сразу после первой итерации. Скорее всего, здесь забыли условие. Возможно, код корректен. Но всё равно он весьма подозрителен и на него стоит обратить внимание.

    А вот ещё похожий цикл:
    int SymbolTable::Symbolize() {
      ....
      if (socketpair(AF_UNIX, SOCK_STREAM,
                     0, child_fds[i]) == -1)
      {
        for (int j = 0; j < i; j++) {
          close(child_fds[j][0]);
          close(child_fds[j][1]);
          PrintError("Cannot create a socket pair");
          return 0;
        }
      }
      ....
    }

    Предупреждение PVS-Studio (библиотека tcmalloc): V612 An unconditional 'return' within a loop. symbolize.cc 154

    Кажется, здесь фигурная скобка закрывается не там, где надо. По всей видимости, код должен был выглядеть так:
    if (socketpair(AF_UNIX, SOCK_STREAM,
                   0, child_fds[i]) == -1)
    {
      for (int j = 0; j < i; j++) {
        close(child_fds[j][0]);
        close(child_fds[j][1]);
      }
      PrintError("Cannot create a socket pair");
      return 0;
    }

    Начало и конец — одно и тоже


    class CONTENT_EXPORT EventPacket {
      ....
      InputEvents::const_iterator begin() const
        { return events_.end(); }
      InputEvents::const_iterator end() const
        { return events_.end(); }
      ....
    protected:
      InputEvents events_;
      ....
    };

    Предупреждение PVS-Studio (Chromium): V524 It is odd that the body of 'end' function is fully equivalent to the body of 'begin' function. event_packet.h 36

    Функции beign() и end() возвращают одно и тоже. Наверное, функция begin() должна выглядеть так:
    InputEvents::const_iterator begin() const
      { return events_.begin(); }

    Неустойчивая функция rdtsc()


    __inline__ unsigned long long int rdtsc()
    {
    #ifdef __x86_64__
      unsigned int a, d;
      __asm__ volatile ("rdtsc" : "=a" (a), "=d" (d));
      return (unsigned long)a | ((unsigned long)d << 32);
    #elif defined(__i386__)
      unsigned long long int x;
      __asm__ volatile ("rdtsc" : "=A" (x));
      return x;
    #else
    #define NO_CYCLE_COUNTER
      return 0;
    #endif
    }

    Предупреждение PVS-Studio (библиотека SMHasher): V629 Consider inspecting the '(unsigned long) d << 32' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. Platform.h 78

    Эта функция частично работает. Однако, она может подвести, если тип long окажется 32-битным. Вот здесь "(unsigned long)d << 32" произойдёт переполнение. Чтобы этого избежать, код надо модифицировать следующим образом:
    return (unsigned long long)a |
           ((unsigned long long)d << 32);

    Великий и ужасный break


    Ключевое слово 'break' постоянно забывают при использовании оператора выбора. Забыть его может кто угодно и когда угодно. Не теряйте бдительность.

    Первый пример:
    static v8::Handle<v8::Value>
    toV8Object(....)
    {
      switch (extension->name()) {
        ....
        case WebGLExtension::WebGLCompressedTextureATCName:
          extensionObject = toV8(....);
          referenceName = "webGLCompressedTextureATCName";
        case WebGLExtension::WebGLCompressedTexturePVRTCName:
          extensionObject = toV8(....);
          referenceName = "webGLCompressedTexturePVRTCName";
          break;
      }
      ....
    }

    Предупреждения PVS-Studio (библиотека WebKit):
    • V519 The 'extensionObject' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 222, 225. V8WebGLRenderingContextCustom.cpp 225
    • V519 The 'referenceName' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 223, 226. V8WebGLRenderingContextCustom.cpp 226
    Обсуждать здесь нечего. Забыли 'break'. Точка.

    Второй пример:
    bool ScriptDebugServer::executeSkipPauseRequest(....)
    {
      const char* v8MethodName;
      switch (request)
      {
        case ScriptDebugListener::NoSkip:
          return false;
        case ScriptDebugListener::Continue:
          return true;
        case ScriptDebugListener::StepInto:
          v8MethodName = stepIntoV8MethodName;
        case ScriptDebugListener::StepOut:
          v8MethodName = stepOutV8MethodName;
      }
      ....
    }

    Предупреждение PVS-Studio (библиотека WebKit): V519 The 'v8MethodName' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 412, 414. ScriptDebugServer.cpp 414

    Андрей Карпов прислал ещё несколько фрагментов кода. Но они не очень интересные, так что я их пропущу.

    Неинтересным я считаю вот такие ляпы:
    int linux_get_device_address (....,
      uint8_t *busnum, uint8_t *devaddr,
      ....)
    {
      ....
      *busnum = __read_sysfs_attr(ctx, sys_name, "busnum");
      if (0 > *busnum)
        return *busnum;
      ....
    }

    Предупреждение PVS-Studio (библиотека LibUSB): V547 Expression '0 > * busnum' is always false. Unsigned type value is never < 0. linux_usbfs.c 620

    Указатель 'busnum' ссылается на беззнаковую переменную, имеющую тип uint8_t. Это значит, что условие (0 > *busnum) никогда не выполнится.

    То есть самая настоящая ошибка. Но скучная. Так что я заканчиваю с описанием ошибок.

    Заключение, или обращение к разработчикам Chromium


    Вы видите, что PVS-Studio регулярно находит ошибки в коде Chromium. Вы видите, что теперь PVS-Studio легко встроить в сборочную систему. Мы готовы всячески вам в этом содействовать, если что-то не будет получаться. Дело за вами – давайте вместе будем повышать качество Chromium. Внедряйте PVS-Studio в своем проекте!

    Напоминаю, что эта статья опубликована и на английском языке. Если захотите переслать ее англоязычным коллегам – пожалуйста, дайте им ссылку вот на это.

    P.S. При написании данной статьи ни одно NDA не было нарушено, вся информация получена из открытых источников.
    PVS-Studio
    1,057.22
    Static Code Analysis for C, C++, C# and Java
    Share post

    Comments 205

      +33
      Реклама этой компании всегда будет только плюсоваться :)
        +36
        Программистам же вообще сложно что-то рекламировать, поэтому приходится искать интересный формат.
        +7
        Выражение «sizeof(P256_SPKI_PREFIX) != 0» всегда ложно.

        Разве не наоборот?
          +2
          Спасибо, поправили. Ошибка была.
            +45
            нашли ошибку в ошибке, обнаруженную при поиске ошибок
              +4
              И, по лицензии, позволили посмотреть на нее один раз :)))
          +13
          Знаю троих разработчиков Chromium, все они не используют Visual Studio и Windows, обходятся текстовыми редакторами вроде vim и Textmate под Linux и OS X. Так что неудивительно, почему у вас все еще нет оффера от Гугла ;)
            +1
            Статья именно для них — киньте им, пожалуйста, ссылку! Собственно теперь нам и не требуется Visual Studio для того, чтобы проверять Chromium.
              +17
              Но все же требуется Windows. Видимо вам все же придется портировать. Пока не будет удобного способа проверять не на машине разработчика, а в облаке, боюсь Гугл на вас и не посмотрит.
                0
                Уже есть способ проверять не на машине разработчика, а в облаке.
                  +9
                  И тем не менее в этой статье вы написали
                  Вы видите, что теперь PVS-Studio легко встроить в сборочную систему.

                  и показали, как это сделать на Windows. Почему бы не сделать пример, как на Linux-машине встроить облачную проверку в сборочную систему?

                  Кстати, а в чем все-таки причина отсутствия nix-версии? Не видно рынка, или сложность портирования?
                    +3
                    Почему бы не сделать пример, как на Linux-машине встроить облачную проверку в сборочную систему?


                    Мы делали проверку Chromium и на Linux. Все прошло без проблем, все работает. Описывать это в статье… Ну тогда бы статья была не 13 листов, а 20. И точно никто бы не прочитал.

                    Кстати, а в чем все-таки причина отсутствия nix-версии? Не видно рынка, или сложность портирования?


                    Мы не умеем продавать Linux-продукты. Не видим рынка, не умеем. Положа руку на сердце, кроме «энтузиастов» с Хабра вопросов про Linux-версию очень мало. А энтузиасты — они же не покупают.
                      +7
                      Вопрос цены. Энтузиасты всегда пробуют что-то новое, а потом приходят на работу и говорят: «Надо купить то-то и то-то, это серьезно улучшит стабильность нашего кода и сэкономит нам время на написание не тривиальных тестов».
                        0
                        >Мы не умеем продавать Linux-продукты.

                        А модель сервиса вы всерьез рассматривали? Если при текущей модели ваш потолок (IMHO) — несколько сотен крупных проектов, которые посчитают оправданным встроить анализ в ежедневный workflow, то в модели сервиса вы можете заполучить и тысячи и десятки тысяч обычных команд, которые будут проверяться, скажем, раз в месяц или даже раз в год.
                          +3
                          , которые будут проверяться, скажем, раз в месяц или даже раз в год.

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

                          Если Вы не согласны, немедленно отключите все предупреждения в компиляторе, и включайте их раз в месяц или даже в год. :)
                            +1
                            Не понимаю, в чем тут обман, объясните.
                            Конечно, это не самый эффективный способ, но почему он «неправильный», если поможет исправить накопившиеся ошибки?
                              +1
                              Такой подход имеет смысл, если команда, например, переносит код на 64-битную систему. Тогда открыли 100500 сообщений, выданных модулем Viva64 и начали усердно рефакторить код. Потом, анализатор можно выбросить и писать новый код уже правильно. Собственно, Viva64 так и преподносился, как инструмент миграции. Использовать его потом или нет — это уже по желанию.

                              В случае статического анализа общего назначения, основный смысл — регулярное его использование. Оно позволяет выявить ляпы и опечатки на самом раннем этапе. От этого собственно и есть основная польза.

                              Если этого не делать, эти ошибки в своём большинстве будут выявлены чуть позже другими (дорогими) способами. А на этапе запуска PVS-Studio от ошибок останутся рожки и ножки. В основном они будут находиться в крайне редко используемых участках кода. Например, в обработчиках ошибок. Кстати, именно это часто можно наблюдать в моих статьях. Многие другие ошибки, которые мог бы найти PVS-Studio, уже исправлены кровью и потом.

                              Так какой смысл предлагать ужасный способ использования?
                                +9
                                Даже одноразовая проверка полезнее её отсутствия.
                    +3
                    Наверняка тесты Хромиума бегают в том числе на Виндовых машинах.
                      0
                      Я практически уверен, что на виндовых машинах в Гугле бегают только Вин-специфичные тесты, а все остальные — на линуксовых. Так что присоединюсь к «оракулам» выше/ниже: оффера не будет пока не появится полноценный линуксовый порт.
                          0
                          Где это там написано, что на винде бегают только тесты, «специфические для винды»? Как вообще понять, какой тест «специфический», если другой компилятор может даже самые базовые вещи по-другому реализовывать или оптимизировать?
                            –3
                            Читайте между строк и используйте логику. Там написано, что у них есть некоторое количество Вин-машин, но добавление еще одной — тот еще гемор, и добавить линуксовую намного проще. С увеличением кодовой и тестовой базы нужно наращивать вычислительную мощь. Если для Вин-специфичных вещей выбора нет, то там, где выбор есть, он будет явно сделан в пользу Линукса.
                              +2
                              Где Вы это всё там вычитали? Там написано, что добавление сервиса под Виндой труднее. При этом не написано, что невозможно и не написано ничего на счёт добавления машин. На счёт выбор есть\выбора нет — пользователи винды очень существенная (большая?) часть юзеров Хрома. Билд для них собирается студией. Что такого страшного, чтобы этот билд проверять какими-то инструментами, заточенными под винду или студию?

                              P.S. Вы понимаете, что проверять под линуксом билд Хромиума под gcc — не даёт права говорить об отсутствии багов под студией?
                                –2
                                Вы думаете, я сейчас буду доказывать вам, что мое толкование слов автора того комментария более правильное, чем ваше? Ошибаетесь. Каждый волен в своих заблуждениях.
                                  +1
                                  Безусловно. Я просто пытаюсь понять как Вы выводите валидность скомпилированного Visual Studio кода под Винду на основе каких-бы то там ни было проверок, пусть самыми лучшими инструментами, которые предлагаете делать только под Linux.
                                    +1
                                    >Я просто пытаюсь понять как Вы выводите валидность скомпилированного Visual Studio кода под Винду на основе каких-бы то там ни было проверок

                                    Начнем с того, что системы статического анализа не проверяют валидность скомпилированного кода. Они проверяют сам код.

                                    Далее, большая часть кода как вебкита, так и хромиума в целом, платформо-независима. Они даже от STL постарались максимально уйти, и у них свои строки, свои контейнеры, и куча всего другого, которое живет в подпроекте с говорящмм названием «WTF» (нет, не то, что вы подумали, а Web Templates Framework :))
                                    То есть практически весь «общий» код независим от платформы даже на уровне библиотек. Соответственно, различия начинаются только когда дело касается, скажем, рендеринга, и тут начинается полный Вавилон: тут вам и WinApi, и Cairo, и хренова туча других зверей разной степени монструозности. И вот именно эту часть нужно проверять на целевой платформе, тогда как большую часть WebCore, JavaScriptCore, WTF и т.д. — не нужно.
                                      +1
                                      К сожалению, Вы не совсем правы. Это в теории, проблемы только в платформо-зависимых местах. А на практике, код из Chromium:

                                      typedef UINT_PTR SOCKET;
                                      
                                      SOCKET socket_;
                                      
                                      int TCPServerSocketWin::Listen(....) {
                                        ....
                                        socket_ = socket(address.GetSockAddrFamily(),
                                                         SOCK_STREAM, IPPROTO_TCP);
                                        if (socket_ < 0) {
                                          PLOG(ERROR) << "socket() returned an error";
                                          return MapSystemError(WSAGetLastError());
                                        }
                                        ....
                                      }
                                      


                                      Этот код вполне «платформо-независим», но при этом не работает в Windows.

                                        +1
                                        Меня терзают смутные сомнения по поводу платформо-независимости класса с названием TCPServerSocketWin
                                          0
                                          Да, это наверное к Win относится. Однако, это пример очень распространенного паттерна ошибок. Код вроде переносим, но не совсем. И не в Windows выявлен не будет. Сюда написал, первое что попалось под руку. Уверяю, можно подыскать и другие примеры.
                                            +2
                                            Не понимаю, поясните.

                                            Дано: общий код, который используется и под Windows, и под Linux. Запускаем PVS-Studio под Linux. Если в каком-то конкретном общем участке кода есть ошибка, то она будет выявлена вашим алгоритмом, так? Ему же пофигу, в какой среде он исполняется, правила-то одни и те же.

                                            Глюки, которые проглатываются msvs и выскакивают в gcc (равно как и наоборот) мы не рассматриваем — у вас ведь полностью свой анализатор, я правильно понимаю?
                                              +1
                                              Правила одни и те-же. А типы разные. В Linux тип SOCKET будет знаковым и никакую ошибку выявить невозможно. Конкретно для данного случая можно сделать особое правило. Но в целом, при смене типов что-то будет по другому. По хорошему, вообще надо проверять в разных режимах. В прочем это тема требует отдельного рассмотрения. Я просто хотел показать, что всё всегда сложнее, чем кажется. И успешные тесты обобщенного кода в одной системе, не обязательно гарантируют работоспособность в другой.
                                                0
                                                Ваш пример выше отлично иллюстрирует, что даже когда типы имеют одинаковое название, все равно платформо-специфичная реализация выносится в отдельный класс, а там уже и инклюды свои, и код тоже свой, и компилироваться он будет только под свою платформу.
                                                В вебките это повсеместно (достаточно заглянуть хотя бы в любой подкаталог в Source/WebCore/platform/* или любом другом компоненте), и у меня очень сильное подозрение, что в Хромиуме используется тот же подход.
                                                  +1
                                                  Нет. Вы не осознали глубину всех глубин. :)

                                                  Вот код (это не Chromium, но не суть важно):

                                                  static int hash_void_ptr(void *ptr)
                                                  {
                                                    int hash;
                                                    int i;
                                                  
                                                    hash = 0;
                                                    for (i = 0; i < (int)sizeof(ptr)*8 / TABLE_BITS; i++)
                                                      {
                                                        hash ^= (unsigned long)ptr >> i*8;
                                                        hash += i * 17;
                                                        hash &= TABLE_MASK;
                                                      }
                                                    return hash;
                                                  }
                                                  


                                                  Код общий. Однако, как будет работать хеш-функция зависит от платформы. Беда — обрезание старших битов при явном приведении типа "(unsigned long)ptr". Причина — разная модель данных (long может быть 32-битным или 64-битным в 64-битных программах).
                                                    +1
                                                    Хорошо. Как работает — зависит от платформы. А PVS-Studio предупреждение выдаст тоже в зависимости от платформы? Если она будет запущена на «беспроблемной» платформе, то предупреждение выдано не будет?
                                                      0
                                                      Конечно, не будет. Псевдокод:

                                                      #if define(_WIN32)
                                                        typedef UINT_PTR MY_HANDLE;
                                                      #else
                                                        typedef long MY_HANDLE;
                                                      #endif
                                                      MY_HANDLE x = foo();
                                                      if (x < 0)
                                                        Error();
                                                      


                                                      На что ругаться, если это не Win?
                                                        +1
                                                        >На что ругаться, если это не Win?

                                                        Эта фраза куда лучше смотрится вне контекста ;)

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

                                                        Было бы очень интересно посмотреть на наличие таких косяков именно в коде Вебкита/Хромиума. И это как раз очень важно ;)
                +45
                И этого оффера скорее всего не будет, пока не появятся порты PVS на Linux и OS X.
                0
                на с траницу с англоязычной версией неплохобыло бы добавить возможность комментировать статью
                  +2
                  Можно комментировать на ycombinator.
                    +1
                    в этом случае следует в конце статьи поместить ссылку, либо везде указывать только ссылку непосредственно на hacker news
                  0
                  Ошибка в tcmalloc присутствовала еще в прошлый раз. Тогда PVS не умел находить ошибки такого рода, или по какой-то причине пропустил ее?
                    +10
                    Если ошибка существует давно, то возможны 3 варианта:

                    1) Не умел. Анализатор постоянно развивается. Причем добавляются не только новые диагностики, но и совершенствуются старые.

                    2) Я просто её просмотрел в прошлый раз.

                    3) Статьи получаются слишком большие и мне приходится иногда исключать описание некоторых предупреждений. Иначе это уже будет не статья, а безжалостный скучный отчёт.
                    +3
                    Я правильно понимаю, что вы отредактировали build.ninja? Он ведь генерируется. Это нормально для ручной проверки, но плохо для проверки на билдботах. Ожидаемый интерфейс для подобных вещей это GYP-variables и переменные среды. С правкой build.ninja можно жить, но разработчикам это не понравится.
                      +1
                      Да, все правильно. Интеграция в GYP — это отдельная задача, которую выполнить «с улицы» невозможно. Нам же надо было показать принципиальную возможность встраивания. Что мы и сделали. Готовы помочь команде Google с интеграцией в GYP. Пишите нам.
                      +28
                      Немного оффтоп, но я зашел на сайт узнать стоимость PVS-Studio и не нашел ее, вместо этого мне предлагают обратиться к поддержке. Я не потенциальный покупатель, но даже мне это показалось странным. На сайтах расширений, которыми я пользуюсь стоимость указывают (ReSharper, NCrunch). У меня возникло ощущение, что вы можете менять стоимость в зависимости от платежеспособности клиента у это не вызывает положительных ассоциаций.

                      Может это одна из причин, по которой Гугл не хочет использовать PVS-Studio?
                        0
                        Может это одна из причин, по которой Гугл не хочет использовать PVS-Studio?

                        Уж точно не причина
                          +2
                          При этом у них везде написано что типа у них цены прозрачные и не зависят от объемов проекта :)
                            0
                            Вот тут все расписано. Там целая история, а внизу статьи есть цены.
                              0
                              Да, спасибо, интересно прочитать. Ту статью я пропустил. Но не каждый додумается искать цену инструмента на хабре.
                                –1
                                А почему бы не написать в поддержку?
                                  0
                                  Как я писал выше, я не собирался покупать продукт, но интересен был порядок цен. И мне показалось странным что цены скрываются от пользователя.
                                  А касательно других инструментов — цена на сайте помогает быстро сориентировать стоит ли дальше интересовать инструментом или нет. Например, ReSharper и NCrunch порядка $160 — приемлемо, а Xamarin за $999 за платформу — неприемлемо.
                                    –4
                                    Удивляют комментарии от тех, кто не собирается покупать продукт, но считает просто необходимым высказаться.
                                      0
                                      Я стараюсь писать комментарии по делу. И мне кажется, это как раз тот случай, когда комментарий стоило написать. Меня удивляет ваша реакция, ведь обратная связь от сообщества должна высоко цениться.
                                        –2
                                        Меня удивляет количество людей, которым продукт не нужен, но считают своим долгом оставить комментарий и посоветовать как надо правильно. Из-за этого реально полезные отзывы оказываются пропущенными.
                                          +1
                                          Если я знаю ценовую политику на инструмент заранее, и попадаю в проект, в котором он пригодится — обычно я могу сразу сказать/порекомендовать приобрести.

                                          К примеру, зная, что бюджет на одну покупку до $300, я не стану рекомендовать выедать мозг через «request a quote» на продукты SciTools, когда есть более чем вписывающийся в этот бюджет и под требования Source Insight.

                                          Но это ничто. А вот вопрос «качественная поддержка либо кряк» звучит поинтереснее.
                            –1
                            1. А где баг репорты в проекте хромиум? code.google.com/p/chromium/issues/list (может по этому и не пишут вам)
                            2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
                            3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
                            4. Как я вижу, большинство ошибок не в самом хромиуме, а во всяких инкапсулированных библиотеках. Благо хоть WebKit они мучают без оглядки на Apple…
                              –2
                              Баг-репорты в Chromium пишут тут: crbug.com.
                              +6
                              2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.

                              Отлично. Вот только вопрос, почему тогда я нашел эту ошибку? :)
                              Быть может, мы делаем что-то лучше?

                              3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.

                              Думаю, у некоторых от этой фразы будет истерический смех.

                                +1
                                Отлично. Вот только вопрос, почему тогда я нашел эту ошибку? :)
                                Быть может, мы делаем что-то лучше?

                                1. Видимо народ не особо смотрит на ворнинги при -Wall
                                2. Безусловно вы делаете, что то лучше иначе не было бы в вас смысла. К тому же вы узкоспециализированный инструмент и вы можете «бить в одну точку»…

                                Думаю, у некоторых от этой фразы будет истерический смех.

                                Если вы про то, что гугл и так использует Valgrind то я знаю — видимо мало смотрят. Если вы про то, что Valgrind находит мало ошибок — достаточно, коль даже их пропускают. Лучше поясните причину смеха этих «некоторых».
                                  +2
                                  После огромных усилий, которые Google тратит на написание надежного кода, создания специальных инструментов для поиска ошибок, учреждает награду за поиск ошибок, брошенная в воздух фраза «могли бы тем же Valgrind помучать хотя бы», звучит как злая усмешка.
                                    +2
                                    Видимо все их усилия не очень хорошо окупаются. Почему? Вот это и есть вопрос. Судя по тому, что не исправлены стандартные предупреждения gcc то либо у них нету времени на вылизывание кода (тесты проходит и ладно), либо они в целом этим не занимаются.

                                    создания специальных инструментов для поиска ошибок

                                    занимается отдельный отдел, который хорошо себя пиарит.

                                    Я не утверждаю всё выше написанное, это только догадки. А вы думаете это всё потому, что их инструменты плохи и они просто не видят всех этих ошибок?
                                      +1
                                      Нет, просто писать программы сложно. И все допускают ошибки.
                                        +2
                                        Тогда ещё один инструмент поиска ошибок погоды не сделает, и серебряной пули для ошибок проекта не станет.
                                          0
                                          Вы думаете компания разработчик софта надеется на серебряную пулю?
                                            +4
                                            Нет конечно, но внедрение чего то должно быть обоснованно как логически так и экономически.
                                            Каков будет эффект от внедрения вашего продукта если они уже используют много чего, но продолжают пропускать -Wall?
                                              0
                                              Почему Вы думаете, что в Chromium не используется -Wall?
                                                0
                                                Кто сказал, что не используется!? Просто игнорируется его вывод… :) выше же нашли ошибки/предупреждения которые отлавливает gcc.
                                                  +1
                                                  И даже -Werror вроде как используется.

                                                  Однако, не в сторонних библиотеках — по весьма прагматическим причинам…
                                                    0
                                                    Об этом я то же писал. Теперь вопрос к PVS почему они приводят примеры ошибок из сторонних библиотек? :)
                                                      0
                                                      Чтоб страшнее получилось ;)
                                                        0
                                                        Потому, что Chromium более чем на половину состоит из сторонних библиотек. Впрочем, какие они сторонние, если над многими работают всё те же люди.
                                                          0
                                                          Кстати, вот это интересно — получается, какие-то из «своих» сторонних библиотек компилируются без -Wall -Werror?
                                                          У Вас есть такие данные под рукой?
                                                            0
                                                            Я не знаю. Меня спросили, «вопрос к PVS почему они приводят примеры ошибок из сторонних библиотек?». Я ответил. Не более того.
                                                              0
                                                              Ладно, всё равно спасибо что вскопали эту возможную проблему.
                                          +1
                                          Судя по тому, что не исправлены стандартные предупреждения gcc то либо у них нету времени на вылизывание кода (тесты проходит и ладно), либо они в целом этим не занимаются.

                                          Это происходит потому, что сейчас Windows-версия Chromium собирается не с помощью GCC, а с помощью MSVC.

                                          В долгосрочных планах переход на clang, когда он начнет хорошо работать под Windows (работы над этим ведутся при активном участии разработчиков из Google).
                                    –1
                                    Плюсую за «а где баг репорты в проекте хромиум?»

                                    и минусую за «могли бы тем же Valgrind помучать хотя бы»
                                    build.chromium.org/p/chromium.memory.fyi/console
                                      0
                                      Как я писал выше, я знаю что проект использует активно valgrind и прочие инструменты. Похоже я слишком резко высказался… мысль была такая: «по чаще бы они смотрели в Valgrind» :)
                                        0
                                        Ещё как смотрят!

                                        Билдботы автоматически отправляют разработчикам персонализированный email «ты сломал вот это вот здесь» в течении 30-90 минут с момента коммита в репозиторий.
                                          +1
                                          Но ведь ошибки всё равно есть. :) И это похоже не по тому, что у них нету PVS.
                                            0
                                            Я думаю тут скорее проблема не в том, что «не все смотрят выдачу валгринда», а в том что динамический анализ (valgrind, etc) принципиально не может находить некоторые виды ошибок, которые может находить статический анализ (PVS).

                                            Уверен на 146%, что если бы в хроме не применялся тот же Valgrind, AddressSanitizer и кучу чего ещё, то PVS находил бы не десяток интересных ошибок раз в полгода, а гораздо-гораздо больше.
                                              +1
                                              то PVS находил бы не десяток интересных ошибок раз в полгода, а гораздо-гораздо больше.


                                              Можно сказать «десяток ошибок раз в полгода», а можно — при «каждом запуске PVS-Studio находятся ошибки». Политический окрас уже другой :-)
                                                +2
                                                Ну не я же trying selling PVS-studio to Google ;)
                                        –3
                                        Плюсую за «а где баг репорты в проекте хромиум?»

                                        Казалось бы в баг-треккере?
                                          +4
                                          Довольно странное у вас представление о баг-репортах…
                                            0
                                            Покажите, пожалуйста, как надо. На примере этой заметки.
                                              +4
                                              Посмотрите внимательнее на коммент #2.

                                              Что это значит?
                                              Разработчики Chromium (N штук) прочитали ваш пост, после чего каждый второй
                                              — полез в багтрекер искать «а не зафайлил ли уже вот эту конкретную ошибку кто-то ещё»,
                                              — обнаружил что «не зафайлил» (90% далее были побеждены ленью...).
                                              — начал файлить багрепорт, копипаст, всё такое.
                                              Потом pkasting@ добавил зависимости части этих багов основному метабагу.

                                              Минусы для Chromium:
                                              1) сам по себе баг «посмотрите вот эту ссылку, там куча найденных ошибок» не несёт полезной информации, учитывая что ссылка на каждый новый пост про Chromium на вашем сайте мгновенно появляется на chromium-dev
                                              2) с момента public disclosure (а ведь это могут быть и security баги, за которые Chromium даёт четырёхзначные награды) до момент фикса проходит лишние несколько часов/дней просто из-за того, что кто-то должен зафайлить и т.п.
                                              3) часть найденных багов может потеряться по дороге (не факт, что это происходит на практике)

                                              Минусы для вас:
                                              1) У багов, найденных PVS, нету в трекере лейбла «найдено PVS studio», поэтому их сложнее искать
                                              2) Даже если бы такой лейбл был, количество находимых багов получилось бы заниженным, т.к. не всем багам заводится issue
                                              3) Вы не можете/вам неудобно следить за прогрессом по багам, например «пофикшено», «ой какая классная система», «баг неинтересен», «бага нет».

                                              Рекомендация:
                                              Находите новую багу — зафайлите crbug.com/new независимо от желания писать в обозримом будущем пост.
                                              Баги вполне можно файлить в формате «имя файла с ошибокй, сниппет кода, очень краткое объяснение ошибки», без нерелевантной мишуры из серии «UserAgent».
                                              Когда зафайлили критическую массу багов — пишете пост «как обычно», для каждой ошибки указывая ссылку на её crbug.

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

                                              Понимаю, что это немного лишней работы вашей команде (честно — действительно немного, я таких багов сотнями файлил и жив пока), которая на мой взгляд окупится вниманием и лояльностью.
                                              0
                                              Роман, мы очень рады, что Вы заботитесь о качестве open-source. Вы можете очень легко помочь разработчикам Chromium. Скачайте исходные коды Chromium. Скомпилируйте. Если что-то не получится, мы или люди из Google подскажут. Мы с радостью бы дали уже имеющийся отчёт, но он на данный момент уже устарел. Напишите нам в почту. Мы выдадим Вам на время PVS-Studio, чтобы Вы имели возможность полноценно и внимательно проверить и проанализировать отчёт. После этого, разобравшись, что из сообщений является ошибкой и как её необходимо исправить, Вы сможете предложить репорты по их исправлению. Ведь я рассматривал только небольшую часть подозрительных мест. Общество Вам будет благодарно.
                                              Ждём Вас с вопросами в почте.
                                                +2
                                                Пришлите мне лучше имеющийся отчёт, я разберусь с diff-ом исходников. Windows у меня нет ни на одной машине, а возиться с PVS и wine нет никакого желания.
                                                Адрес моей почты можно получить, заменив подчёркивание в моём нике на точку и дописав в конце @ gmail.com.
                                                Заодно посмотрю, что из отчёта найдёт анализатор clang.
                                                  –2
                                                  Нет, так не пойдет. Вы опять просите нас сделать за вас работу?
                                                    +4
                                                    сделать за вас работу

                                                    Нет, что вы. Наоборот, это я хотел сделать часть работы за вас. Но что-то в ответ вижу какие то унылые шуточки.

                                                    Если уж на то пошло, то инструменты вроде вашего как раз и должны делать нудную работу за разработчика. Ребята из JetBrains, к примеру, борятся за каждую мелочь, чтобы сделать процесс разработки приятнее. За это их очень многие любят.
                                                      0
                                                      Объясните хотя бы, за что минусы в карму.
                                                        –6
                                                        Наверное, кому-то не понравилось что-то © К.О.
                                                      +1
                                                      Простите, а что именно не так в предложении?

                                                      Просьба, как по мне, вполне здравая, по крайней мере потому что у Вас этот отчёт уже есть, а время на полный анализ проекта, размерами с Chromium будет довольно большим, особенно если у roman_kashitsyn нет под рукой мощного сервера для такого анализа, ведь Cromium с сопутствующими библиотеками это несколько сотен МБ кода.

                                                      На счёт wine я тоже соглашусь, он, к сожалению, очень кривой, и при анализе такого большого объёма данных велика вероятность, что анализ в wine не удастся выполнить вообще по причине не стабильной работы :( А ставить Windows, пусть и в виртуалку довольно бестолковое занятие поскольку анализатору всё таки лучше дать ресурсов по максимуму, а накладные расходы на окружение минимизировать, я уже молчу о том, что эта затея выглядит странной для однократного использования.

                                                      p.s: у меня сейчас в wine под Ubuntu не ставятся даже редистрибутейбл от 2012 и 2013 студии, ставится только от 2010, при том не ставятся тихо, мирно, и совершенно молча, просто не запускаясь :( Сам мучаюсь с некоторым софтом, ибо нативную реализацию под *nix делать слишком накладно, а для работы в wine приходится либо функционал местами урезать, либо костыли городить, а самое обидное, что каждая следующая версия wine начинает вести совершенно иначе.
                                                    +2
                                                    Шелдон чувстовать сарказм.

                                                    Зря вы так. Если меня что-то не устраивает в open-source проектах и я могу это исправить — я это делаю.
                                            +3
                                            Сомневаюсь, что сборка Chromium происходит под win. Без адекватного порта PVS смысла в нем мало.
                                            А нерабочие && (указанные в документации) в конфиге ninja, это не знак ли того, что документация под *nix? Там это корректный оператор, а что в виндовом cmd с ним происходит — хз.
                                              +1
                                              Вы думаете, Chromium не собирается и не тестируется под win (в том числе под win)?
                                                +1
                                                Сборка под win не подразумевает, что компилятор работает под win. Я именно про компилятор.
                                                  +1
                                                  Gyp официально поддерживает генерацию проектов для Visual Studio, сборка под Visual Studio описана в официальной доке. Это как-то совсем было бы глупо — подписываться под поддержкой сборки под VS и при этом генерить бинарники каким-то раком под другими ОС.
                                                    +2
                                                    Под Win используется Visual C++ 2012, которому к сожалению нужна винда.
                                                      +1
                                                      Понятно. А вообще что-то из статических анализаторов у вас используется (вы написали, что не относитесь к build infrastructure, но вдруг в курсе)?
                                                      Тем более это может быть начинание конкретных разработчиков, а не «план партии».
                                                        +1
                                                        Во-первых, в clang и gcc включены -Wall -Werror. Во-вторых, иногда используется valgrind. В-третьих (хотя это уже не совсем то), в самом коде используется достаточно много проверок, макросы типа DISALLOW_COPY_AND_ASSIGN() в каждом классе, проверка правильности треда в начале каждого метода.
                                                  +3
                                                  Chromium под Windows компилируют с помощью Visual Studio, а Visual Studio на Linux не работает. Поэтому приходится собирать его под Windows. К тому же, все равно нужно пускать тесты под Windows. С кросс-компиляцией при тестировании возникает множество проблем, поэтому она используется только для arm'a.
                                                  +4
                                                  Не уверен, что им нужен PVS Studio, если Google себе может позволить Coverity, Klockwork, или даже Polyspace, а это продукты совсем другой весовой категории…
                                                    +2
                                                    У них, на мой взгляд, также достаточно ресурсов, чтобы допилить статический анализатор clang до нужного уровня. Возможно, разработчиков Chromium просто не особо задумываются о статическом анализе…
                                                      –3
                                                      Нет, если уж допиливать, то анализатор Frama-C — допиливать много меньше, только поддержку C++ добавить.
                                                        +6
                                                        допиливать много меньше, только поддержку C++ добавить

                                                        действительно, делов-то

                                                        С учётом масштаба инфраструктуры llvm и того факта, что большая часть разработчиков этого проекта работают в Google, вариант допиливания clang мне кажется более правдоподобным. Написали же они рантаймовые MemorySanitizer, AddressSanitizer, ThreadSanitizer, etc., да и статический анализ уже есть, только, быть может, не такой глубокий.
                                                          0
                                                          Ну, SMT решатель, формализатор кода (преобразование к IL) — доже дело не такое простое… А это всё уже есть в Frama-C, причем в виде плагинов — можно использовать несколько.
                                                            +5
                                                            <sarcasm>
                                                            Так сходу сложно сказать, что написать проще — SMT решатель или парсер c++
                                                            </sarcasm>
                                                        –1
                                                        Ну, valgrind, к примеру, для Хрома используется.
                                                          +1
                                                          valgrind вещь хорошая и очень полезная, но к статическому анализу кода она никакого отношения не имеет
                                                            +2
                                                            Ок, согласен, строго говоря это не статический анализ. Из статического только gcc, clang и lint.
                                                        –1
                                                        Только мы не видим от них (Coverity, Klockwork) статей про то, как интегрировать их продукт с кодовой базой Chromium что-то…
                                                          +2
                                                          У Klockwork очень удобный web-интерфейс отчетов, причем можно интегрировать в систему Code Review — таким образом происходит профилактика внесения ошибок, и удобство просмотра отчетов анализатора. Так же он интегрируется и с багтрекинговой системой — опять таки очень удобно.
                                                            +3
                                                            Coverity интегрируется — инфа 100% ;)
                                                          +26
                                                          Я — разработчик Chromium (хотя и не занимаюсь build infrastructure), так что могу высказать некоторые предположения, почему у нас не используется PVS-Studio.

                                                          1. Абсолютное большинство разработчиков используют Linux, так что напрямую использовать PVS не смогут. На втором месте из операционных систем, по-моему, OS X.

                                                          2. Большая часть инфраструктуры (билд, тест и т.д.) тоже на линуксе, и изменить это достаточно сложно.
                                                          Конечно, некоторое количество машин для сборки и тестирования на Windows есть, но добавить лишний сервис на Windows значительно сложнее, чем лишний сервис на Linux.

                                                          3. Chromium — open source проект и прилагаются усилия к тому, чтобы любой разработчик со стороны мог проделать с ним все необходимые действия: собрать, протестировать и т.д.
                                                            0
                                                            И как это мешает отделу Google, который занимается выпуском Chrome, применять PVS-Studio и отправлять коммиты с исправленным кодом в Chromium?
                                                              +5
                                                              Я ж говорю. Тем, что PVS-Studio не работает на Linux. Плюс, мне кажется неправильным, что такой вид тестирования будет доступен только отдельным разработчикам с лицензией.
                                                                –2
                                                                Работает (в Wine). Мы не стали это в статье отмечать, что запускались в Linux. Скажем так, это интимный режим работы, который стоит обсуждать отдельно с потенциальными пользоателями. :)
                                                                  +31
                                                                  Делать билд Хрома зависимым от Wine? Нет, спасибо.
                                                                    +2
                                                                    Хм, а почему? Чем wine как рантайм хуже того же python?
                                                                      +3
                                                                      Стабильностью, к примеру.
                                                                        +1
                                                                        Я так понимаю это мнение с потолка? Или просто спекуляция, основанная на размере коммунити?
                                                                          0
                                                                          Я пользовался тем и другим.
                                                                            0
                                                                            Подозреваю, Вы запускали тяжёлые сложные игры или программы на Wine и относительно небольшие скрипты на Python, а не наоборот.
                                                                              +2
                                                                              На питоне я запускал всё что только можно, от маленьких проектов до очень больших. Никогда проблем не было.

                                                                              С вайном вылезают иногда некоторые проблемы уже на сравнительно простых утилитах. Ну то есть какой-нибудь winzip ещё скорее всего пройдёт без проблем, а если что-то сложнее — то уже на факт.
                                                                  0
                                                                  Т.е. пусть лучше софт будет с багами, чем отдельные разработчики будут иметь софт с лицензией, которую им и сейчас ничего не мешает купить?
                                                                  И создать особую тестовую среду для программу, которой пользуются сотни миллионов человек вроде довольно правильное решение, если это не чрезмерно сложно. Есть какая-то сложность, чтобы тестировать Chromium под Windows?
                                                                    +7
                                                                    Софт будет с багами в любом случае, увы. Вопрос в их количестве, критичности и том, как наиболее эффективно использовать ресурсы, чтобы от них избавиться. Я пока не убеждён, что установка предлагаемого продукта себя оправдывает. (И я ничего на эту тему не решаю.)

                                                                    > И создать особую тестовую среду для программу

                                                                    Такая тестовая среда есть: build.chromium.org/p/chromium/waterfall

                                                                    > Есть какая-то сложность, чтобы тестировать Chromium под Windows?

                                                                    Да, есть. В рамках инфраструктуры Гугла поддерживать лишний сервис на Linux гораздо проще чем на Windows. Для Win нужна либо виртуализация, либо ручная поддержка серверов. Плюс, нужна обвязка, которая будет из общего билд-процесса будет вызывать какие-то операции на винде.
                                                                      +1
                                                                      Действительно, я не учёл баланс, всё верно.
                                                                +1
                                                                Пробовали регистрироваться на Coverity Scan for Open Source?
                                                                  +1
                                                                  Лично я — нет. Насколько я понимаю, настроить работу любого такого статического анализатора с Хромом — достаточно большая работа. (Кроме, быть может, Valgrind, который сразу с бинарником работает.)
                                                                    0
                                                                    Все правильно. И мы эту работу сделали.
                                                                      +4
                                                                      Осталось всего ничего: сделать это для требуемой платформы, а не для той, которую вы посчитали нужной.
                                                                        –1
                                                                        Мы это сделали в том числе и для Linux.
                                                                          +5
                                                                          Судя по всему, вы сделали это для Wine, а не для Linux. Реакция немного предсказуема
                                                                            –10
                                                                            Я Вам, кстати, тот же вопрос задам, что и автору того комментария.

                                                                            Дело в том, что я уверен, что Вы и eterevsky — самые обычные юниксовые красноглазики вот в каком смысле: вы поддерживаете позицию, что делать билд хрома зависимым от wine — плохо. Но! (тут потребуется Ваша честность в ответе на вопрос)

                                                                            1.Задумались ли Вы, прежде, чем излагать эту мысль или соглашаться с ней, что именно плохого в добавлении wine в список зависимостей для сборки Chrome? Меня серьёзно интересует ответ на этот вопрос, т.к. именно он определяет наличие «красноглазия».

                                                                            Опережая некоторые варианты ответа спрошу:
                                                                            2. Чем в это смысле wine отличается, например, от того же Python или Perl, которые в самом Хроме не используются, но нужны для сборки. Или, в данном случае, даже apache, который нужен для выполнения некоторых тестов (как раз случай PVS-Studio)?
                                                                              +11
                                                                              >Дело в том, что я уверен, что Вы и eterevsky — самые обычные юниксовые красноглазики вот в каком смысле: вы поддерживаете позицию, что делать билд хрома зависимым от wine — плохо. Но! (тут потребуется Ваша честность в ответе на вопрос)

                                                                              То есть я заранее в положении красноглазика, который сейчас попытается доказать, что он не красноглазик? :D Извините, но я принципиально не буду отвечать на вопрос, поставленный таким образом. Я давно вырос из возраста «в интернете кто-то неправ», а уж рассказывать про очевидные вещи «чем зависимость от Wine отличается от зависимости от Python» — это я даже не знаю…
                                                                              Я не просто «задумывался» об этом, я совершенно точно знаю, почему это принципиально разные вещи.
                                                                                –4
                                                                                Ну так поделитесь своим знанием. Интересно же.
                                                                                  +14
                                                                                  Когда интересно, тогда вопросы задают более вежливо — это вам на будущее.

                                                                                  Не понимаю, почему у вас такой вопрос вообще возникает. Для получения ответа достаточно представить теоретическую, но воплне рабочую ситуацию: решение внедрили, и вдруг возникла проблема. Скажем, после очередного коммита в репозиторий процесс проверки начал завершаться с ошибкой. Что имеем в случае питоньих зависимостей? Имеем сами тесты, stack trace с указанием места ошибки, и полный набор инструментов для решения проблемы (начиная от кода тестов и заканчивая кодом интерпретатора питона). Что имеем в случае сабжа под Wine? Stack trace, на который смотрим, как баран на новые ворота: кода нет. Начинаем общение с разработчиками, разработчики отфутболивают к Wine, открещиваются от версии X, заявляют, что поддерживают только версию Y, и так далее и тому подобное. И я даже не беру в рассмотрение тот факт, что вероятности возникновения ошибки в интерпретаторе питона и в Wine различаются на пару порядков.

                                                                                  Минорный апдейт питона? Никто ничего не заметит. Минорный апдейт Wine? Здравствуйте, новые глюки, за которые никто не отвечает. Я был бы рад услышать от разработчиков PVS-Studio «мы будем поддерживать любую версию Wine на любом дистрибутиве», но я вам гарантирую, что этого мы не услышим — им для этого штат нужно будет в несколько раз расширить (куда больше, чем для создания нативного порта — но они ведь и этого не делают). А значит что? А значит максимум, что они выкатят — это поддержку конкретной версии Wine на конкретном дистрибутиве. И версия эта будет обновляться очень и очень неспешно, раз эдак в пару лет в лучшем случае.

                                                                                  И Гуглу предлагается за свои же деньги влезть в подобную кабалу? Да им проще Klocwork купить и не парить мозг. Ну и выплачивать премии за найденные баги.

                                                                                  Общая и главная мысль: сравнивать системы нужно не только с точки зрения «как оно работает», но и «что делать, когда оно не работает». Это не менее (а то и более) важный показатель при сравнительном анализе систем.
                                                                                    –5
                                                                                    Насчёт вежливости вопроса. Я не увтерждал, что вы — красноглазики. Я только сказал, что я так думаю, а это — разные вещи. В принципе ваш первый ответ про «Совершенно точно знаю» как раз соответствовал этой гипотезе.

                                                                                    Вопрос был Wine vs нативный порт на Linux. К чему вы приплели пустые стектрейсы? Wine открытый и его стектрейс при желании можно посмотреть. Что касается PVS студии, то её стектрейс вы бы и на нативном порте не увидели.

                                                                                    А вы разработчиков спросили, готовы они поддерживать каждую новую версию Wine? Я вот уверен, что они готовы.

                                                                                    А про минорный апдейт Wine — снова ваши домыслы, непонятно на чём основанные.
                                                                                      +5
                                                                                      >Я не увтерждал, что вы — красноглазики. Я только сказал, что я так думаю, а это — разные вещи

                                                                                      Вы сказали, что уверены в этом, а не «думаете», а это — разные вещи.

                                                                                      >А вы разработчиков спросили, готовы они поддерживать каждую новую версию Wine? Я вот уверен, что они готовы

                                                                                      А я вот уверен, что не готовы. Чья уверенность увереннее?

                                                                                      >А про минорный апдейт Wine — снова ваши домыслы, непонятно на чём основанные.

                                                                                      И вы, разумеется, снова в этом уверены?

                                                                                      Вот я, к примеру, уверен, что вы спорите ради самого спора. Вы просили поделиться моими соображениями — я это сделал, а вот непременно доказать вам свою точку зрения и в чем-то убедить — такого желания у меня как-то не возникает. Имеющий уши — да услышит.
                                                                                +3
                                                                                Я бы не отказался от возможности отказаться от Perl'a. А Apache я совсем не давно удалял из системы, после того, как мне его поставил скрипт установки зависимостей хрома (я не запускаю тесты, в которых он используется). А в этом баге люди уже второй год пытаются избавиться от cygwin'a: crbug.com/123026. Добавление новой зависимости для всех разработчиков — это очень плохо, добавление новой зависимости только для одного билдбота — нормально. Если же нужна группа билдботов, то уже нужно писать какие-то скрипты для автоматической установки/настройки и обновлять их. Задача значительно усложняется.

                                                                                Вообще, в выборе между wine и нативным Windows, я бы предпочел нативный Windows. Дело в том, что когда программу пускают десять/сто раз в день при распараллеливании на один-другой десяток процессоров, программы начинают сбоить самыми загадочными способами. Разбираться в сбоях wine'a в дополнение к сбоям программы мне не хочется.
                                                                                  0
                                                                                  Понятно, что многим не нравится, когда у проекта куча зависимостей. У меня на работе ситуация та же. Вплоть до того, что используются разные версии одной и той же утилиты. Но, надо признать, после однократной настройки всё работает очень и очень долго и лишее беспокойство пока не доставляет. И тут уже вопрос в том, стоят ли преимущества того объёма работы, который нужно осуществить. А объём работы не выглядит очень уж большим.

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

                                                                                  Насчёт нативный Windows. Ты говоришь так словно в Wine полно багов и сбоев, гораздо больше, чем в том же Python. Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.

                                                                                  Спасибо за развёрнутый осмысленный ответ, кстати. Когда поднимаешь явно холиванрые темы, редко такие ожидаешь.
                                                                                    +4
                                                                                    Python содержит очень мало низкоуровневых API, реализация которых может вызвать сложности на Windows/Linux. Дополнительно, он хорошо защищен от многих проблем распараллеливания, поскольку использует процессы вместо потоков.

                                                                                    В Native Client, где POSIX-like api эмулируется поверх Windows и мы столкнулись с кучей проблем, когда некоторые вещи оказывается не возможным сделать на Windows. В Wine свое множество подобных проблем совместимости, которые готовы выстрелить в самый не подходящий момент параллельного билда. Когда количество запусков порядка десятка тысяч, проблемы начинают случаться регулярно. Если зависимость от wine будет на всех линуксовых ботах, проблемы будут случаться всегда. После этого, станет не возможным определение последней зеленой ревизии, которая используется, в частности, для релиза хрома.

                                                                                    PS По аналогичной причине не рекомендуется запускать 32-битный Native Client в виртуальной машине. Работа с сегментными регистрами в них плохо протестирована. Из-за этого возникают уязвимости, позволяющие выйти из сандбокса. 64-битный Native Client сегментных регистров не использует (да и не может использовать), поэтому работает под виртуальными машинами стабильно.
                                                                                      +1
                                                                                      Вопрос в том, какой subset API использует утилита командной строки PVS-Studio. Я как раз о том, что да, в вайне наверняка полно багов в COM, DirectX, DCOM и т.п. Но я почти на 100% уверен, что всё, с чем работает PVS-Studio — это консоль, файловый ввод-вывод и переменные окружения, которые уже давно оттестированы и перетестированы.
                                                                                      +3
                                                                                      >Ты говоришь так словно в Wine полно багов и сбоев, гораздо больше, чем в том же Python

                                                                                      Вы так говорите, как будто вода мокрая, железо тяжелее воды, а на тело в окрестностях Земли действует сила притяжения, пропорциональная массе тела :)

                                                                                      >Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.

                                                                                      С одной конкретной версией PVS-Studio под одной конкретной версией Wine на одном конкретном релизе одного конкретного дистрибутива — да, проблем не возникло. Вас ничего не настораживает в этой цепочке? ;)
                                                                                        0
                                                                                        > Вы так говорите, как будто вода мокрая, железо тяжелее воды, а на тело в окрестностях Земли действует сила притяжения, пропорциональная массе тела :)

                                                                                        И всё же, я уверен, что у Вас данных, чтобы это утверждать никаких нет. А если и есть — то это сравнение работы тяжёлого софта на Wine против чего-то довольно простого на Питоне. То есть данные явно недостаточные, чтобы сравнить с «железо тяжелее воды».

                                                                                        > С одной конкретной версией PVS-Studio под одной конкретной версией Wine на одном конкретном релизе одного конкретного дистрибутива — да, проблем не возникло. Вас ничего не настораживает в этой цепочке? ;)

                                                                                        Ну если проблема в дистрибутиве, то она может быть и в Питоне. Проблема версии Питона тоже может иметь место быть. А насчёт конкретной версии студии, очевидно же, что если Гугл купит, то они постараются, чтобы версия PVS проблем не создавала.
                                                                                          +2
                                                                                          >И всё же, я уверен, что у Вас данных, чтобы это утверждать никаких нет. А если и есть — то это сравнение работы тяжёлого софта на Wine против чего-то довольно простого на Питоне.

                                                                                          Интересно, на чем основывается ваша уверенность… Давайте так: я сообщаю вам, что участвовал в разработке проекта на Питоне, кодовая база которого перевалила за 300К строк (и это при том, что Питон — ну очень лаконичный язык), а вы обещаете, что больше не будете обобщать свой опыт на окружающих. Договорились? ;)
                                                                                          И были в этом проекте и сеть, и ORM, и multi-threading, и собственный REST-сервер с не одним десятком методов, и чего там только не было (то есть шансов напороться на грабли в интерпретаторе, сами понимаете, были весьма велики), однако интерпретатор фиксили буквально считаные разы, и то в основном для обхода GIL.

                                                                                          Но вообще мы отдалились от основной мысли. Даже если рассмотреть такой невероятный случай, что багов примерно одинаково, то процесс решения проблем с Python и с Wine+чья-то закрытая разработка различается кардинально.
                                                                                            0
                                                                                            Ок, вопрос, сколько раз вы фиксили баги в Wine? 0? То есть сравнение всё же вашего опыта на Python с ничем? Замечу, что проблемы с интерпретатором у вас тоже были. То есть в принципе паритет — баги были и там, и там.

                                                                                            И, ещё раз, диалог — о том, что товарищ не хочет PVS через Wine. А просто PVS он может и взял бы с удовольствием. Я, соответственно, Python сравниваю с Wine, а не с Wine+PVS. Почему вы сравниваете с Wine+PVS я не понял.
                                                                                              +3
                                                                                              1. Я фиксил баги в Wine, самолично для обхода некоторые проблем 1С 7.7. В том числе вручную портировал патчи итерософта в новые ветки. Код wine карйне сложен и нестабилен, а главное ОГРОМЕН по сравнению с интерпретатором Python.
                                                                                              2. Вы сравниваете тёплое с мягким — реализацию всего WinAPI (в том числе с различными интерпретаторами и компиляторами) и всего навсего, интерпретатор языка программирования (даже не компилятор! и без JIT). Они различаются как объёмом кода так и подходу к качеству разработки.
                                                                                                +1
                                                                                                Кстати, еще один небольшой такой факт насчет Python VS Wine применительно к Гуглу: создатель Питона Гвидо ван Россум год назад начал работать в Dropbox, а до этого он на протяжении 7 лет работал… (где бы вы думали?)… в Google! ;)
                                                                                                0
                                                                                                Я не запускал Wine, но зато мне приходилось расследовать ошибки в cygwin, которые проявлялись при запуске компилятора. Более того, все найденные в cygwin ошибки проявлялись бы даже на программе которая использует из всего API только spawn/fork/exec (без каких-либо экзотических опций). Т.е. программе не нужно вызывать вообще никаких функций, чтобы cygwin начал сбоить при параллельной работе. Логично ожидать, что с wine тоже будут подобные проблемы. А находить их очень трудно. Поиск ошибки в cygwin'e занял больше месяца. Более того, вероятность сбоя часто сильно варьируется в зависимости от компьютера. В результате, к примеру, на локальном компьютере я первой нашел ошибку, которая на ботах встречалась в 10-100 раз реже, чем основная ошибка.
                                                                                          +4
                                                                                          Ты говоришь так словно в Wine полно багов и сбоев, гораздо больше, чем в том же Python.
                                                                                          Ну, а ты так говоришь, словно нет. Вот тебе пример: есть два компа с Ubuntu 12.04, на обоих стоит одинаковая версия Wine, на компах разные процы (Intel Core i5 и AMD Phenom II) и разные видюхи (Intel HD Graphics 2500 и GeForce 450 GTS). На первом крэшится даже инсталлятор Far Cry 3, на втором игра устанавливается и работает (с тормозами, разумеется). Вопрос знатокам: можно ли это назвать стабильностью и у кого подобное бывало с Python?

                                                                                          Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.
                                                                                          Странно, но я сделал вывод, что им удалось запустить PVS-Studio в Wine. Наверное, это потому, что я делаю выводы, выводя их логически, а ты выдаёшь желаемое за действительное. Я могу написать, что запустил Far Cry 2 в Wine с драйвером nouveau, но это не означает, что я в него смог поиграть, а не наблюдал вместо этого живописные чёрные леса и холмы без текстур на средних настройках и с дикими тормозами.
                                                                                            –1
                                                                                            > Ну, а ты так говоришь, словно нет. Вот тебе пример: есть два компа с Ubuntu 12.04, на обоих стоит одинаковая версия Wine, на компах разные процы (Intel Core i5 и AMD Phenom II) и разные видюхи (Intel HD Graphics 2500 и GeForce 450 GTS). На первом крэшится даже инсталлятор Far Cry 3, на втором игра устанавливается и работает (с тормозами, разумеется). Вопрос знатокам: можно ли это назвать стабильностью и у кого подобное бывало с Python?

                                                                                            У меня проблемы с Питоном были даже на hg-subversion, который от силы несколько тысяч строк кода. А ты с Far Cry 3 сравниваешь. Это как раз то, о чём я говорил в предыдущем комментарии. Вы все делаете вывод о том, что Wine в сравнении с Python не стабилен на основании того, что под ним не работают стабильно такие монстры как Far Cry. Но ведь у Вас даже нет рабочих примеров такого же масштаба на Питоне. А вот если сравнивать какие-нибудь консольные утилиты, работающие только с файлами да переменными окружения, каковой PVS-Studio, скорее всего, и является, много по-вашему сбоев будет?

                                                                                            > Странно, но я сделал вывод, что им удалось запустить PVS-Studio в Wine. Наверное, это потому, что я делаю выводы, выводя их логически, а ты выдаёшь желаемое за действительное. Я могу написать, что запустил Far Cry 2 в Wine с драйвером nouveau, но это не означает, что я в него смог поиграть, а не наблюдал вместо этого живописные чёрные леса и холмы без текстур на средних настройках и с дикими тормозами.

                                                                                            Это был не вывод, а спекуляция на имеющихся данных. Раз они написали целый пост на хабре специально для гугла и в комментариях указали, что у них всё работает, значит проблем не было совсем или было мало и они их решили.
                                                                                              +1
                                                                                              Быть может, дело в hg-subversion? Far Cry 3 был просто приведён в качестве примера. Потрудись зайти на Wine AppDB, посмотреть, сколько приложений из общего количества имеют статус Platinum, и сделать соответствующие выводы. Напоминаю: Platinum означает, что все функции приложения работают не хуже, чем в Windows (полная совместимость).
                                                                                                +2
                                                                                                Platinum — совсем не гарантирует, что работают все критичные функции — яркий пример Photoshop CS2 — не работает поддержка графических планшетов wacom — а без них по сути в большинстве случаев не возможно использовать программу по назначению. Скорее всего Platinum значит, что программа запускается и не должна падать в процессе работы.
                                                                                                +2
                                                                                                >Раз они написали целый пост на хабре специально для гугла и в комментариях указали, что у них всё работает, значит проблем не было совсем или было мало и они их решили.

                                                                                                … или решили не заострять на них внимание, т.к. цель — продать продукт.
                                                                            0
                                                                            3. Chromium — open source проект и прилагаются усилия к тому, чтобы любой разработчик со стороны мог проделать с ним все необходимые действия: собрать, протестировать и т.д.


                                                                            Все правильно. Не имею ничего против того, чтобы Google приобрел такую лицензию.
                                                                              0
                                                                              Вы имеете в виду запуск PVS-Studio в cloud? На серверах Google или на ваших?
                                                                                0
                                                                                Я имею ввиду, что если Google заинтересован в том, чтобы кто-то использовал в команде PVS-Studio — мы рады. Если Google заинтересован в том, чтобы ВСЕ разработчики Chromium использовали PVS-Studio (или могли) мы тоже рады. Как это реализовать — вопрос обсуждений и переговоров. Можем хоть программно-аппаратный комплекс продать, который будет выкачивать свежие исходники и проверять их :-).
                                                                                  +8
                                                                                  Я просто пытаюсь представить модель того, как может быть устроено использование этого тула в билде Хрома. На данный момент почти все инструменты, используемые при сборке Хрома отвечают следующим требованиям:

                                                                                  1. Open source.
                                                                                  2. Работают под линукс и OS X.
                                                                                  3. Могут запускаться на билдботах.
                                                                                  4. Могут точно также запускаться на машине разработчика.

                                                                                  В случае PVS-Studio есть проблемы со всеми этими пунктами. Понятно, что если результат того стоит, то чем-то можно поступиться, но мне сходу вот неясно, стоит ли овчинка выделки.
                                                                                    –9
                                                                                    Олег, Вы должны понимать, что наша маленькая команда сама себе зарабатывает деньги. И мы не можем просто так делать open source и под linux не имея финансирования. Есть ли в этом проблема? Да, есть :-).
                                                                                      +24
                                                                                      Евгений, я понимаю, что ваша маленькая команда так зарабатывает деньги. Но это, к сожалению, не достаточный повод, чтобы Гугл покупал ваш продукт на неудобных ему условиях. It's just business.
                                                                                        0
                                                                                        Олег, а вариант, в котором облако PVS-studio будет брать dev-версию кода, анализировать и выдавать отчет в удобном для вас формате, возможен?
                                                                                          0
                                                                                          Это не вполне укладывается в существующую систему waterfall тестов и создаёт лишний, параллельный существующему механизм сообщения об ошибках. При том, что сборка Хрома — уже сейчас хрупкий и сложный процесс.

                                                                                          P.S. Согласен с этим комментарием.
                                                                                        +7
                                                                                        Евгений, вот от этого ответа вы могли бы и воздержаться, дабы не терять лицо.
                                                                                        Не нужно оправдываться. Вас никто не просит сейчас же, немедленно сделать ваш продукт open-source. И вам не стоит становиться в позу просителей, да еще перед человеком, который не принимает решения.

                                                                                        Зарабатывайте деньги и развивайте технологию без помощи Гугла.
                                                                                        +3
                                                                                        Лично я вижу только один способ — запуск PVS-Studio на отдельном билдботе с Windows. Шерифы будут смотреть на отчеты, когда бот будет становится красным и откатывать изменения по git/svn blame. Учитывая время работы (при ежедневом обновлении webkit'a практически не избежна полная перекомпиляция проекта), запуск на трайботах или машине разработчика не имеет смысла. Люди из Build Infrastructure конечно Windows не любят, но процесс добавления или удаления ботов с Windows все равно происходит регулярно, так что они умеют это делать.
                                                                                        0
                                                                                        Программно-аппаратный комплекс? Xeon Phi?
                                                                                          0
                                                                                          Что это сразу «Пфи-и-и...»
                                                                                            0
                                                                                            Кроме шуток, у меня есть наброски экспериментов анализа на Phi.
                                                                                    0
                                                                                    Свершилось: PVS-Studio для Linux.
                                                                                    +3
                                                                                    т.к. на данный момент анализатор PVS-Studio поддерживает только ОС Windows
                                                                                    1. Проприентарное.
                                                                                    2. Не кросс-платформенное.

                                                                                    И нафига оно сдалось?
                                                                                      +1
                                                                                      И нафига вам комментировать, если нафига сдалось?
                                                                                        +11
                                                                                        Может для того, что бы получить опровержение и доводы в сторону использования?
                                                                                          0
                                                                                          Доводы в сторону использования — найденные ошибки. В том числе, база ошибок в open source проектах, найденных с помощью PVS-Studio.
                                                                                            0
                                                                                            Их можно найти только используя ваш инструмент? Если нет, тогда он мало помогает делу.
                                                                                              +5
                                                                                              Код можно скомпилоровать только с помощью Visual Studio? Нет, значит Visual Studio не помогает.
                                                                                                0
                                                                                                Если проект успешно использует mingw и в качестве редактора/IDE что то другое, то нет не помогает в задаче скомпилировать проект. Но вообще вы путаете тёплое с мягким. Причины использования VS и вашего инструмента различны, это совсем разного класса ПО.

                                                                                                Тут скорее другая аналогия: народ пропалывает грядки вручную, а вы предлагаете куртую и сложную технику для этого. Проблема не в том, что техника плоха или есть лучше конкуренты проблемы в том, что народ в принципе плохо смотрит на любую технику.

                                                                                                Если бы выбор был между инструментом 1 и вашим инструментом 2 который лучше то вопросов нету. Но выбора тут такого нету и он находится в другой плоскости.

                                                                                                Им бы начать по полной использовать те инструменты, что у них есть… и по больше времени на QA тратить.
                                                                                      +6
                                                                                      Учитывая что цену не пишете, речь идет о четырехзначной цене на продукт. Не слишком ли дорого за полезный, но второстепенный тул? Visual Assist на 1 пользователя стоит от 99 долларов, и это не подписка.

                                                                                      Сделайте «indie» лицензию на 1 пользователя, плюс поддержку xcode (c++, objC не нужен) за фиксированную разумную цену — и я ваш.
                                                                                        +1
                                                                                        70 тыс. рублей за огнетушитель — это слишком дорого? Больнице или нефтехранилищу — нет. Вам, вероятно, да, но у вас и риски не те.

                                                                                        Мне кажется, что, исходя из декларируемой функциональности и заявленной стоимости, очевидно, что инди-разработчики не являются целевой аудиторией данного продукта, и предъявлять компании какие-то претензии на эту тему бессмысленно.
                                                                                          +2
                                                                                          Во-первых, исходя из декларируемой функциональности, я делаю вывод что данный софт мне потенциально интересен.

                                                                                          Никто не предъявляет претензии — в топике ясно написано «как мы пытаемся продать..». Я не гугл, но не думаю что автору статьи интересно послушать только гугл. Поэтому, со своей стороны высказываю условия, при которых захочу купить этот продукт. Дальше уже дело хозяина софта, решать — поддержать таких как я и предоставить льготные условия лицензирования, или продолжать жаловаться на гугл :).

                                                                                          Скромно предположу, что лучше продать тысячу индивидуальных лицензий по 99 долларов, чем одну энтерпрайзную гуглу, хоть и за 10-20k, тем более что ничего не мешает указать условия для дешевой лицензии, неприемлимые для больших и средних компаний. Поддерживать 1000 покупателей конечно сложнее, чем одного, но это тоже не непреодолимая проблема.
                                                                                            +8
                                                                                            Вот если бы они не «пытались продать», а попытались сделать так, чтобы Гугл купил (а это разные вещи) — дело приняло бы совершенно другой оборот.
                                                                                            Но им уже который год твердят о Linux-порте (как раз в свете того, что крупные компании предпочитают держать билд-фермы именно на Linux), а они все отбрыкиваются «линуксоиды денег не платят, мы лучше знаем»…
                                                                                              +5
                                                                                              Учитывая, что подобные комментарии появляются практически в каждом топике про PVS Studio, полагаю, что автору уже давно неинтересно слушать инди-разработчиков.

                                                                                              Постойте-ка… вот, точно: неинтересно. И на то есть причины. И давайте уже заканчивать обсуждать ценообразование в топиках про PVS Studio: оно такое, как есть, оно обоснованно, оно зафиксировано, оно не изменится, и точка, об этом уже сто раз писали, авторам уже предлагали бизнес-модель, и даже угрожали, это было весело, но сейчас это уже не весело, это скучно, я не могу это больше видеть, зачем я всё это пишу, ааа, хватит, с меня хватит.

                                                                                              Давайте лучше обсуждать, почему порта на GNU/Linux нет, хотя бы закрытого. Mezomish дело предлагает :-)
                                                                                                0
                                                                                                Спасибо за обзорную экскурсию, теперь все ясно. Нет — так нет, все-равно у меня два необходимых условия было.
                                                                                                Без поддержки xcode (или в крайнем случае без интеграции, просто OSX) мне все-равно пока не нужно, VS не использую последние пару лет. Худо-бедный статический анализатор есть и в xcode, хоть он и хуже.

                                                                                                Давайте лучше обсуждать, почему порта на GNU/Linux нет,
                                                                                                А что тут обсуждать? Очевидно, нет ресурсов и/или желания этот порт делать — я бы, кстати, тоже не стал. Тут я с создателями продукта согласен — разработчики под Linux это какая-то экзотика, плюс вряд ли они будут что-то покупать.
                                                                                                  +6
                                                                                                  Разработчики по Linux экзотика? Вы серьезно?
                                                                                                  Скорее разработчики крупных проектов под Windows экзотика.
                                                                                                  OSX и Linux используется во всех крупных компаниях с которыми я имел дело за последние 5 лет.
                                                                                                  Windows стоит только у менеджеров и остального планктона.
                                                                                                    –4
                                                                                                    «Используется» — для разработки коммерческих end-user решений? Не верю. Если все эти крупные компании связаны с Linux по роду деятельности — например, пишут какой-нибудь серверный софт или сугубо специфический (какие-нибудь управляющие станки на линуксе), то можно понять. Если же «крупная компания» делает коммерческий b2c софт, он должен запускаться под Windows, а значит и разрабатываться под Windows тоже. Это тупо удобнее, да и Visual Studio же.
                                                                                                      +1
                                                                                                      А что вас удивляет?
                                                                                                      Или вы думаете что дальше VS программирования нет?
                                                                                                      Я вас обрадую, бизнес софт в большинстве своем пишется на Java.
                                                                                                      Да и удобства по сравнению с OSX как-то сомнительны.
                                                                                                      Вот писать Windows специфичный софт со свистоперделками — да, удобнее на Windows.
                                                                                                        0
                                                                                                        Причем тут java, если мы внутри блога о (C++)-only инструменте? Я именно в разрезе C++ писал.
                                                                                                      0
                                                                                                      Скоро мы узнаем, насколько Вы правы: PVS-Studio для Linux :). Или Linux версия разделит судьбу CppCat.
                                                                                                    +2
                                                                                                    Большое спасибо. Приятно встретить понимание.
                                                                                                      0
                                                                                                      С текущей политикой компании, рядовому хабравчанину эта софтина не интересна. Я тогда совершено не понимаю зачем они тут пиарятся тем более на OpenSource проектах, мне это напоминает издёвку. Типо вон мы написали мега инструмент и нашли сколько ошибок у вас, но мы его вам не дадим и даже не продадим!
                                                                                                        +3
                                                                                                        Говорите, пожалуйста, за себя, а не за «рядового хабравчанина». Этому мифическому герою, невзирая на абсолютную практическую неприменимость, почему-то чрезвычайно интересны посты про Curiosity, или вот про построение отказоустойчивого датацентра. Точно так же и здесь.
                                                                                                          +1
                                                                                                          Я тут много чего написал… и в итоге стёр. В двух ваших примерах я понимаю какую новую информацию я получу (а значимость миссии НАСА так вообще трудно сравнивать с чем либо), но тут я не понимаю. Мы вроде и так знаем какие типы ошибок может отслеживать продукт, зачем нам ещё одно подтверждение? И не забывайте, что в начале поста они пафосно заявили, что хотят это продать в Google не имея даже unix версии и совместимости с gcc.
                                                                                                          Предположим мне даже понравились возможности, но я даже купить не могу этот продукт, не говоря о том что Windows видел лет 10 назад, как дома так и на работе (Linux, FreeBSD, MacOSX винда только у менеджеров и бухов).
                                                                                                          Ну и процитирую их:
                                                                                                          Поскольку мне интересно, что я делаю не так, и почему Google пока не использует PVS-Studio, я решил написать очередную статью.

                                                                                                          т.е. статья не для нас с вами, а для гугла или разработчиков chromium (которые тут то же есть, но не большинство).
                                                                                                          Одно дело помогать OpenSource, другое дело злорадствовать… про отсутствие багов в багтрекере по каждому пункту, уже сказали многие.

                                                                                                          Ну и всё, выше сказанное я говорю за себя, надеюсь я тут не один такой.
                                                                                                +3
                                                                                                Хороший отчёт, на этот раз ошибки веселее, чем в Geant4. Пишите ещё :-)
                                                                                                  +4
                                                                                                  «Одноразовый» цикл — это немного «индусский», но корректный, метод получения первого элемента итератора, и NULL в случае пустого итератора.
                                                                                                    0
                                                                                                    Ага, использовал тут по рабочим нуждам кусок хрома — webrtc, бывший libjingle, там напихано всякой всячины в third_party типа openssl, jsoncpp, libjpeg, sqlite. У sqlite одного сотни тысяч тестов. Так что ничего удивительного, что десятки тысяч тестов прогоняются. Для продукта с миллионом возможностей это реально мало, это подтверждается тем, что ошибок в нём достаточно.
                                                                                                    По поводу кода у меня ещё сложилось стойкое ощущение, что люди не пользуются ни нормальной IDE, ни анализаторами кода, не умеют разрешать зависимости, не знают, что такое git submodules, не осилили make, ещё основываются на том, что у всех установлен исключительно python2, остальным приходится ставить virtualenv или симлинкать python на python2. Firefox, конечно, не лучше со своим autoconf 2.13.
                                                                                                      +1
                                                                                                      нормальной IDE

                                                                                                      вы знаете нормальную IDE для с++?

                                                                                                      не осилили make

                                                                                                      make особенно удобен под windows, не так ли?

                                                                                                      не умеют разрешать зависимости

                                                                                                      поясните, пожалуйста, что вы имеете в виду

                                                                                                      не знают, что такое git submodules

                                                                                                      А зачем им знать, проект-то под svn

                                                                                                      у всех установлен исключительно python2

                                                                                                      это всё ещё основная стабильная версия python, разве нет?
                                                                                                        0
                                                                                                        Вы сами этот код видели? Не слишком понимаю, с чего бы после этого у вас столько вопросов возникло.
                                                                                                        1. без понятия, но хотя бы одного стиля могли бы придерживаться
                                                                                                        2. причиной для использования scons, а потом создания ninja была другая
                                                                                                        3. действительно ли надо собирать {openssl,sqlite,...}, если достаточно было бы просто для рантайма требовать его установки в системе, а для сборки — его заголовков?
                                                                                                        4. и, спрашивается, почему, потому что он структурирован плохо, а svn всё терпит?
                                                                                                        5. отнюдь нет:
                                                                                                        The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over two years of stable releases, including version 3.3 in 2012. This means that all recent standard library improvements, for example, are only available in Python 3.x.
                                                                                                        (источник)
                                                                                                          0
                                                                                                          There are two recommended production-ready versions at this point in time, because at the moment there are two branches of stable releases: 2.x and 3.x. Python 3.x may be less useful than 2.x, since currently there is more third party software available for Python 2 than for Python 3.

                                                                                                          docs.python.org/3.4/faq/general

                                                                                                          How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.

                                                                                                          Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.

                                                                                                          Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)

                                                                                                          Guido van Rossum Answers Your Questions — August 26, 2013
                                                                                                            +2
                                                                                                            Да, я видел код, когда пытался использовать gyp в своих проектах. Gyp, кстати, отлично задуман, но сыроват для использования вне chromium.

                                                                                                            2. Какая, если не секрет?
                                                                                                            3. И заставлять бедных виндовс-пользователей искать и устанавливать в систему зависимости? И долго разбираться с совместимостью различных версий 3-rd party библиотек?
                                                                                                            Мне гораздо больше нравится идея hermetic builds.
                                                                                                            4. Честно говоря, я большой фанат git. Я считаю его удивительной программой и каждый день удивляюсь, насколько это классный piece of software. Но вот конкретно git submodules я считаю неудачным. Слишком много непонятных ошибок возникает при использовании даже у опытных пользователей.
                                                                                                        +1
                                                                                                        Переменная 'i' похожа на 1.

                                                                                                        void SkCanvasStack::pushCanvas(....) {
                                                                                                          ....
                                                                                                          for (int i = fList.count() - 1; i > 0; --i) {
                                                                                                            SkIRect localBounds = canvasBounds;
                                                                                                            localBounds.offset(origin - fCanvasData[i-1].origin);
                                                                                                        
                                                                                                            fCanvasData[i-1].requiredClip.op(localBounds,
                                                                                                                                             SkRegion::kDifference_Op);
                                                                                                            fList[i-i]->clipRegion(fCanvasData[i-1].requiredClip);
                                                                                                          }
                                                                                                          ....
                                                                                                        }
                                                                                                        


                                                                                                        Слабо заметить подозрительное? :) Анализатору нет.


                                                                                                        Кстати — не слабо :) Тут явно видно, что код криво написан, i в цикле не используется вообще, используется только i-1, а это означает, что надо было это место сразу переписать по нормальному, ну т.е. ещё до того как это попало в репозиторий:

                                                                                                        void SkCanvasStack::pushCanvas(....) {
                                                                                                          ....
                                                                                                          for (int i = fList.count() - 2; i >= 0; --i) {
                                                                                                            SkIRect localBounds = canvasBounds;
                                                                                                            localBounds.offset(origin - fCanvasData[i].origin);
                                                                                                        
                                                                                                            fCanvasData[i].requiredClip.op(localBounds,
                                                                                                                                             SkRegion::kDifference_Op);
                                                                                                            fList[i]->clipRegion(fCanvasData[i].requiredClip);
                                                                                                          }
                                                                                                          ....
                                                                                                        }
                                                                                                        
                                                                                                          +1
                                                                                                          p.s: ну или хотя бы мантейнер должен был отправить такое на ревью до того как это попало в основную ветку.
                                                                                                            0
                                                                                                            p.p.s: и я не знаю какая была логика, хоть она и сохранилась, но у меня ощущение, что они тут обрабатывают не все данные.
                                                                                                            fList.count() - 1 а потом i-1
                                                                                                            
                                                                                                            , ну и я это поправил на
                                                                                                            fList.count() - 2
                                                                                                            
                                                                                                            , что уже явно говорит о том, что обработка одного элемента пропущена.

                                                                                                            Вот и ещё одна идея от диагностики ;)

                                                                                                          Only users with full accounts can post comments. Log in, please.