С целью популяризации методологии статического анализа в целом и анализатора PVS-Studio в частности мы регулярно проверяем различные открытые проекты. Найденные в них баги отлично демонстрируют, что никто не застрахован от опечаток, невнимательности и других ошибок. Именно никто, и подтверждения тому мы находим в таких проектах, как Microsoft Code Contracts, Qt, ядро Linux, CryEngine, VirtualBox, LibreOffice, Firefox, Boost, Tor и так далее. На данный момент нами проверено 262 проекта. И вот свершилось, мы нашли и выписали в базу 10000 багов.Как правило, когда мы находим в проекте достаточное количество ошибок, мы пишем про это статью. Со списком этих статей можно познакомиться здесь. Если же находится всего несколько ошибок, мы просто сообщаем про них разработчикам проекта и продолжаем заниматься другими делами.
Конечно, 10000 ошибок на 262 проекта – это не много. Получается, что в среднем мы нашли 38 ошибок в проекте. Стоит отметить, что на самом деле это число ничего не значит. Размер и качество проектов бывает очень разным. Например, где-то мы находим только одну ошибку, а где-то их сотни.
Ещё важно отметить, что для популяризации статического анализа и PVS-Studio нам не нужно найти как можно больше ошибок. Нам нужно найти количество ошибок, достаточное для написания статьи. Поэтому мы всегда предлагаем авторам проектов проверить их код более тщательно. Да и вообще, разовые проверки проекта хорошо использовать для демонстрации возможностей анализатора, но пользы от них мало. Весь смысл статического анализа в его регулярном использовании. Тогда многие ошибки можно обнаруживать ещё на этапе написания кода, а не через 50 часов отладки или после жалоб пользователей.
Пришло время дать ссылку на собранные ошибки:
База ошибок, обнаруженных в Open Source проектах
Эта база может послужить уникальным материалом для размышлений о разработке стандартов кодирования, написания статей о правилах программирования, и помочь в других исследованиях, связанных с повышением надежности программного обеспечения. Пример: "The Last Line Effect". Желаем интересных исследований.
Комментарии (17)
qw1
18.08.2016 17:07-10Без открытия 10000 тикетов в трекере — не засчитывается, полезного выхлопа нет.
ziv
18.08.2016 17:36+3А если бы вы таки раздавали вашу linux-версию индивидуальным разработчикам, то нашли бы ещё больше.
Написал письмо 28 июля после публикации — даже не ответили.
EvgeniyRyzhkov
18.08.2016 17:37С какой почты писали? Я всем отвечаю, либо не дошло, либо упустили.
ziv
18.08.2016 17:42+1С f2404@… на саппорт@вива64.ком. Только что отправил ещё одно письмо.
EvgeniyRyzhkov
18.08.2016 17:44+2Игорь, извиняюсь. Ваше письмо по какой-то причине осталось не отмеченным. Возможно в тот день было много писем и подвел почтовый клиент – оно сразу пометилось как «прочитанное».
handicraftsman
18.08.2016 19:35Короче говоря, как обычно: распиаривали себя сначала на проприетарщине, а затем начали питаться свободным кодом. А в конце предыдущего топика вообще показалось, что на фоне — люди «нетрадиционной ориентации»
greendimka
18.08.2016 21:47+2Ребята отличную работу делают. Постоянно нахожу грубейшие ошибки в open source проектах — теперь есть программное подтверждение тому, что open source <> качество. Надеюсь PVS заставит авторов делать работу качественно Есть действительно много отличных идей, реализованных, к сожалению, ужасно.
Ag47
19.08.2016 21:24+1Я недавно решил все-таки воспользоваться благами цивилизации и провести статический анализ кода. Раньше слышал про cppcat, полез на сайт и нашел только то, что он уже давно как закрыт. Так я и не понял, если я индивидуальный разработчик и проект у меня для себя, никакого статического анализа мне не полагается?
И еще, конечно, не понять мне видимо никогда, почему по кнопке купить на самом деле купить ничего нельзя.ziv
20.08.2016 11:41+2Кроме PVS Studio, есть и другие статические анализаторы кода: cppcheck и clang-analyzer (оба открытые), Coverity (проприетарный, но у них есть программа работы с открытыми проектами — можно проверить свой код), Klocwork (проприетарный).
Andrey2008
20.08.2016 15:42+1К сожалению, мы не умеем работать в индивидуальные разработчики (не умеем зарабатывать на них деньги). Если Вы представляете какую-то компанию (но планировали использовать анализатор в одиночку), то прошу написать от лица этой компании. Мы считаем, что вся команда и весь проект получает пользу от использования статического анализатора, не зависимо от количества программистов, которые запускают анализатор, и есть смысл говорить о командной лицензии.
Если у Вас хобби-проект или маленький командный проект, то я не думаю, что этом проект требует столь серьезной артиллерии, как PVS-Studio. Предлагаю использовать что-то из бесплатного инструментария (Cppcheck, предупреждения GCC или Clang). У маленьких проектов маленькие проблемы :). В них нет исторического кода, написанного непонятно кем и когда, нет текучки кадров и необходимости контроля новобранцев, в них меньше плотность ошибок, их проще протестировать или сделать code-review, не нужна поддержка сложных систем сборки и ночных запусков анализатора на сервере, не нужно распараллеливаться на IncrediBuild. И так далее. Единственный вариант, который мы предлагаем бесплатным открытым проектам: они про нас статью в своём блоге, мы им ключ для проверки их проекта. Быть может Вас заинтересует такой вариант.ZyXI
20.08.2016 18:45Когда вы выпустите пробник для linux я собирался посмотреть, хорошо ли PVS-Studio работает для Neovim, и если да, то посмотреть, можно ли взять на деньги из bountysource лицензию. Писать на почту в статье просить бету как?то не тянет: нет «корпоративной почты».
Но все проблемы тут есть: исторического кода полно в Vim, ещё больше (бо?льшая часть импортированного из Vim кода может по праву считаться «историческим») у Neovim, написан код далеко не только Bram или maintainer’ами проекта, CI активно используется. «Текучку» определить сложно, но «новобранцы» есть.
Поэтому сейчас вопрос: что нужно иметь в статье, какие и сколько языков и что можно считать блогом: я могу написать сюда (на хабр), есть ещё /r/neovim на Reddit, где?то пишутся новости, есть wiki? В любом случае, ключ без linux?версии нам сейчас не нужен.
Если что, в проекте уже используются предупреждения clang и gcc, статический анализатор clang’а, clang sanitizers (address, undefined behaviour и thread) при прогоне функциональных тестов и coverity. Разумеется, этого недостаточно.
Andrey2008
20.08.2016 20:28На Хабре и reddit мы и так присутствуем. Нас бы устроило упоминание в news. А запрос Linux версии всё-таки сделайте. Уже скоро начнем потихоньку отправлять первые ключи.
akzhan
Спасибо за огромную работу. Я на всякий начал pull request делать, когда есть настроение