Комментарии 75
Очень тихо. Оставлю первый комментарий.
Мы очень любим Linux и теперь будем стараться проверять больше Linux проектов. Спасём Linux от багов!
Мы очень любим Linux и теперь будем стараться проверять больше Linux проектов. Спасём Linux от багов!
А само ядро слабо протестировать? Его, правда и так всё время гоняют под разными анализаторами. Но вдруг найдете парочку новых 0day уязвимостей?
Coming soon…
PVS-Studio покопался во внутренностях Linux (3.18.1): http://www.viva64.com/ru/b/0299/. Но будет и ещё.
Вам, кстати, не помешали бы теги в вашем блоге. Я честно хотел проверить есть ли статья про ядро на сайте. Но просматривать вообще все статьи как-то не с руки. А вот был тег linux…
Ознакомиться с полным списком проверенных проектов можно сразу на одной странице.
А как насчет community edition версии? Я бы вот хотел проверить ядро OP-TEE. А ещё лучше — прикрутить его к travis, что бы он на каждом коммите проверял.
Он реально их находит? Любопытно можно ли отбить деньги на покупку PVS-Studio продавая найденные им 0day уязвимости в открытых проектах?
Ну в ядре он вряд ли найдет что-то. Ядро регулярно проверяется самыми разными анализаторами. Думаю, другие крупные проекты — тоже.
С другой стороны даже одна 0-day уязвимость с RCE скорее всего окупит покупку.
Правда, я не знаю сколько стоит PVS-Studio, потому что автора в лучших традициях не имеет фиксированной цены.
С другой стороны даже одна 0-day уязвимость с RCE скорее всего окупит покупку.
Правда, я не знаю сколько стоит PVS-Studio, потому что автора в лучших традициях не имеет фиксированной цены.
НЛО прилетело и опубликовало эту надпись здесь
А можно PVS-Studio (или какой либо открытый статический анализатор) прикрутить git чтобы на лету проверять корректность загруженного в репозиторий кода и чтобы он подсвечивал сомнительные участки и сам делал посты в багтреккер?
Можно ли натаскать нейросеть не выявление какой либо одной ошибки к коде одного конкретного языка программирования?
Можно ли натаскать нейросеть не выявление какой либо одной ошибки к коде одного конкретного языка программирования?
Первое в принципе осуществимо. Есть git hooks, есть jenkins, есть плагины дженкинса к всяким треккерам.
А вот второе — очень интересная исследовательская задача. Лично я о таком не слышал.
А вот второе — очень интересная исследовательская задача. Лично я о таком не слышал.
Промазал с ответом, но ладно.
Первое — не правильно!
Первое — не правильно!
Почему неправильно? Я где-то видел такой вариант. git hook триггерит job на jenkins, тот в свою очередь проверяет проект. Правда, таски автоматически не создавались. Но зато он умел отписываться в уже существующие таски, если их упоминали в commit message.
Всё правильно, есть много способов автоматизировать проверку и сделать рассылку людям, которые закоммитили этот код. Но такой код не должен попадать в репозиторий. В идеале.
А выявление ошибки уже на этапе проверки, например, на сервере, говорит о том, что кто-то подзабил на анализ.
А выявление ошибки уже на этапе проверки, например, на сервере, говорит о том, что кто-то подзабил на анализ.
Ну я всё-таки привык к модели принятой в open source. С обязательным code review живыми людьми. Если перед этим сервер сам автоматически прогонит патч на статическом анализаторе — это плюс.
Конечно, я понимаю, что это противоречит вашей бизнес модели и вы хотите что бы копия анализатора стояла на машине каждого разработчика… Но называть сходу «неправильным» такой подход нельзя.
Конечно, я понимаю, что это противоречит вашей бизнес модели и вы хотите что бы копия анализатора стояла на машине каждого разработчика… Но называть сходу «неправильным» такой подход нельзя.
Это методология статического анализа, а не бизнес-модель. Мы продвигаем именно методику, в которую входят разные способы контроля качества кода, На примере нашего анализатор. Code Review тоже часть методологии. Но если бы Code Review был так эффективен, то не было бы статических анализаторов — по сути это инструменты автоматического Code Review.
Ну вот именно. А теперь берем инструмент для ручного code review такой как gerrit или тот же github. Они все работают как сервера. Потому что удобно в одном месте видеть и комментарии других разработчиков и отчет системы статического анализа. В конце-концов разработчик может запушить патч забив на сообщения анализатора. А вот когда анализатор сидит на сервере и ставит таким патчам "-1" — это совсем другое дело.
По вашей модели мне придется слить патч себе, запустить анализатор локально, что бы убедиться что к патчу нет претензий и только потом делать review глазами.
Удобней же, когда ты открываешь патч и видишь, что вот система CI прогнала тесты и ничего не упало, статический анализатор не нашел ничего криминального, checkpatch говорит что с форматированием всё в порядке, живые люди поставили плюсики…
По вашей модели мне придется слить патч себе, запустить анализатор локально, что бы убедиться что к патчу нет претензий и только потом делать review глазами.
Удобней же, когда ты открываешь патч и видишь, что вот система CI прогнала тесты и ничего не упало, статический анализатор не нашел ничего криминального, checkpatch говорит что с форматированием всё в порядке, живые люди поставили плюсики…
Вы используете gerrit?
На прошлых проектах использовали всегда. Сейчас мы работаем в основном с open source комьюнити и поэтому пушим патчи в мейнлайн по их правилам.
Тогда давайте обсуждать конкретные случаи, когда они будут, а не теоретические. По нашему опыту обсуждение теоретических случаев не дает практически полезных результатов.
Так я и говорю. На предыдущих проектах мы всегда использовали gerrit. Это конкретные случаи. Извините, NDA не позволяет указывать названия проектов.
На некоторых проектах был прикручен klocwork в качестве статического анализатора, на некоторых jenkins проверял не сломается ли билд. А ещё был бот который запускал checkpatch. На некоторых проектах это всё работало вместе. И всё это добро писало комментарии прямо в gerrit и сразу же ставило оценку. Было очень удобно. Это самый что ни на есть конкретный случай.
Нечто подобное сейчас есть на гитхабе. Каждый патч может проверятся travis`ом, анализироваться с помощью coverity, благо они легко интегрируются с гитхабом и доступны бесплатно независимым разработчикам. В результате прямо в pull request виден результат анализа и прямо там есть ссылка на страничку с деталями. Это тоже практика.
На некоторых проектах был прикручен klocwork в качестве статического анализатора, на некоторых jenkins проверял не сломается ли билд. А ещё был бот который запускал checkpatch. На некоторых проектах это всё работало вместе. И всё это добро писало комментарии прямо в gerrit и сразу же ставило оценку. Было очень удобно. Это самый что ни на есть конкретный случай.
Нечто подобное сейчас есть на гитхабе. Каждый патч может проверятся travis`ом, анализироваться с помощью coverity, благо они легко интегрируются с гитхабом и доступны бесплатно независимым разработчикам. В результате прямо в pull request виден результат анализа и прямо там есть ссылка на страничку с деталями. Это тоже практика.
Для расширения кругозора, есть такой коммерческий продукт от очень известной конторы — TFS.
В нём есть настройка (по умолчанию — отключена), что любой коммит, отправляемый на сервер проходит стадию сборки и тестирования на build-станции ДО собственно внесения его в основную ветку разработки. Основной недостаток у этого подхода — от нажатия кнопки «отправить» до результата (успех/провал) проходит значительное время: делается клон основного репозитория, накладываются вносимые изменения, производится сборка и запуск автоматических тестов.
Так что этот подход уже давно применяется и не относится к «бизнес-модели» обсуждаемого тут продукта, равно, как и не требует установки не рабочее место каждого разработчика.
В нём есть настройка (по умолчанию — отключена), что любой коммит, отправляемый на сервер проходит стадию сборки и тестирования на build-станции ДО собственно внесения его в основную ветку разработки. Основной недостаток у этого подхода — от нажатия кнопки «отправить» до результата (успех/провал) проходит значительное время: делается клон основного репозитория, накладываются вносимые изменения, производится сборка и запуск автоматических тестов.
Так что этот подход уже давно применяется и не относится к «бизнес-модели» обсуждаемого тут продукта, равно, как и не требует установки не рабочее место каждого разработчика.
Вы кажется меня не поняли. То что вы описали — это continuous integration. Она может быть реализована разными средствами: в TFS, с помощью Travis, Jenkins и т.д. Можно интегрировать её с code review. Можно заставить систему CI гонять статический анализатор. Можно интегрировать статический анализатор с системой code review. Можно запускать его локально на машине разработчика. Всё можно.
Но тут приходят чуваки из PVS Studio и говорят что правильный только один вариант — запускать статический анализатор на машине разработчика. А все остальные варианты — неправильные. Я с этим не согласен, о чем и написал.
Но тут приходят чуваки из PVS Studio и говорят что правильный только один вариант — запускать статический анализатор на машине разработчика. А все остальные варианты — неправильные. Я с этим не согласен, о чем и написал.
А вы нас не поняли.
Мы говорим, что МАКСИМАЛЬНЫХ результатов можно добиться, если запускать анализ кода и на машине разработчика, и на сервере (ночью или каждый коммит) — уже детали.
Причина проста.
Если анализ запускается на локальной машине до того как код будет на сервере, то анализатор для программиста — это друг, который предотвратил появление ошибки.
Если анализ запускается только на сервере, то анализатор враг, так как позорит программиста перед коллегами.
Вы можете сколько угодно говорить: «Ой, да ладно, что такого, что другие увидят про мою ошибку», но психология людей работает именно так.
Мы говорим, что МАКСИМАЛЬНЫХ результатов можно добиться, если запускать анализ кода и на машине разработчика, и на сервере (ночью или каждый коммит) — уже детали.
Причина проста.
Если анализ запускается на локальной машине до того как код будет на сервере, то анализатор для программиста — это друг, который предотвратил появление ошибки.
Если анализ запускается только на сервере, то анализатор враг, так как позорит программиста перед коллегами.
Вы можете сколько угодно говорить: «Ой, да ладно, что такого, что другие увидят про мою ошибку», но психология людей работает именно так.
Ну наверное мы с вами в разных командах работаем. У нас в команде реакция на замечания в code review приблизетльно одинакова: «ой, провтыкал, сейчас исправлю». Какой толк злиться и обижаться на коллегу если он нашел в твоем коде реальную ошибку? А как можно злиться на анализатор кода — я вообще не представляю. Это всё равно что обижаться на warning от компилятора.
Но я понимаю что в менее сыгранных командах всё может быть совсем по другому. В том числе и боязнь опозориться перед коллегами.
Но я понимаю что в менее сыгранных командах всё может быть совсем по другому. В том числе и боязнь опозориться перед коллегами.
Я говорю про людей. Поверьте, что я их видел некоторое количество и знаю, о чем говорю.
Ну я тоже вроде не с роботами работал.
Просто разные проекты, разные команды, разные требования к разработчикам. В том числе и к общей адекватности. У нас тут в embedded всё строго, выжывают только сильнейшие :)
Просто разные проекты, разные команды, разные требования к разработчикам. В том числе и к общей адекватности. У нас тут в embedded всё строго, выжывают только сильнейшие :)
Верить-то верю, но не понимаю какие проблемы это вызывает. В смысле, всё равно многие тулзы (valgrind, coverity и т.д.) вынужденно запускаются на билд-серверах. Плюс некоторые проблемы вылазят только на отдельных платформах. Люди могут обижаться/раздражаться и… что? Начнут бастовать и требовать отключить всё это дело ради душевного спокойствия?
Мне кажется, что если continuous integration уже имеется и статический анализатор просто добавится к этому списку, то дискомфорта это ни у кого не вызовет.
И уж если говорить о людях, то запускать вручную анализ каждый раз они могут и будут лениться. (:
а если у нас например будет корпоративный git внутри ЛВС, очень удобно будет, особенно при импорте открытого кода из разных проектов для их объединения в своём, например legasy кода от предыдущего исполнителя. я думаю это реально много времени сэкономит. можно было бы Овнеру проекта сделать условие внесения кода в основную ветвь — прохождение без предупреждений PVS-Studio.
А если вы прикрутите PVS-Studio к github или чему то подобному…
Я немного не понимаю как выглядит проверка кода я должен загрузить ком в MSVisualStudio и проверить PVS-Studio или я могу PVS-Studio проверять каждый вечер несколько репозиториев на корпоративном github-е?
А если вы прикрутите PVS-Studio к github или чему то подобному…
Я немного не понимаю как выглядит проверка кода я должен загрузить ком в MSVisualStudio и проверить PVS-Studio или я могу PVS-Studio проверять каждый вечер несколько репозиториев на корпоративном github-е?
А можно PVS-Studio (или какой либо открытый статический анализатор) прикрутить git чтобы на лету проверять корректность загруженного в репозиторий кода и чтобы он подсвечивал сомнительные участки и сам делал посты в багтреккер?
Тут вы уже слишком далеко зашли с ошибками) Программист должен проверить анализатором код изменённых файлов, а только потом делать коммит в репозиторий.
Можно ли натаскать нейросеть не выявление какой либо одной ошибки к коде одного конкретного языка программирования?
Натаскать, наверное, можно. Но никто не пробовал, чтобы посмотреть на результат.
После каждой статьи радуюсь что %product_name% станет лучше и быстрее. Это вдохновляет, спасибо.
Странно, почему после четырех репортов они все еще не купили ваш продукт?
Странно видеть первую ошибку. Её должен был бы отловить Clang-tidy misc-redundant-expression, созданный одним из разработчиков Chromium.
Кстати, а можно ли было бы повторит анализ LLVM/Clang/Clang extra tools/LLD/LLDB/Polly/compiler-rt/libunwind/libcxx/libcxxabi/Include What You Use/Clazy?
Кстати, а можно ли было бы повторит анализ LLVM/Clang/Clang extra tools/LLD/LLDB/Polly/compiler-rt/libunwind/libcxx/libcxxabi/Include What You Use/Clazy?
Non-void function should return a value
Очень странно, что это не поймал компилятор. Хотя, по крайней мере в VS это по умолчанию то ли отключено, то ли варнинг. А на деле это крайне жёсткий баг. Особенно когда возвращается не ссылка (тут программа хотя бы сразу упадёт, если ничего не вернуть), а, например, int. В результате вернётся мусор, и можно очень долго ничего не замечать. Сам в своё время поимел кучу геморроя с такой хренью.
Ну а break в switch'е вообще рептилоиды придумали для завоевания Земли. Как и возможность написать "=" вместо "==" в сравнении.
возможность написать "=" вместо "==" в сравненииЭто вполне легальная операция, кстати.
if ( a = foo() ) { ...одновременно и присваиваем результат переменной «а» и проверяем его на неравенство нулю, эквивалент:
a = foo();
if ( a != 0 ) {...Легальная, но вредная.
Естественно, легальная. И раньше сам так писал. А теперь, много раз налетев на эти детские грабли, считаю, что за это нужно очень сильно бить.
Легальная — до тех пор пока нулевой код не начинает обозначать отсутствие ошибки :) После этого красота такого подхода куда-то исчезает...
Когда планируется поддержка Visual Studio 15?
На Хабре решили не публиковать, а то зачастили. Но возможно читателям будет интересен очередной пример проверки проекта под Linux. Это CodeLite.
Linux-версия PVS-Studio не смогла обойти стороной CodeLite
Linux-версия PVS-Studio не смогла обойти стороной CodeLite
Заранее прошу прощения за оффтопик.
У проекта cURL недавно был security audit. И в посвящённой этому статье они пишут:
https://daniel.haxx.se/blog/2016/11/23/curl-security-audit/
Было бы интересно, наверное, посмотреть, найдёт ли там что-то PVS-Studio после такое основательной чистки. Да и сам проект достаточно «весомый», я бы сказал.
(в вашем списке упоминания cURL я не нашёл)
У проекта cURL недавно был security audit. И в посвящённой этому статье они пишут:
We run static analyzers on the code frequently with a zero warnings tolerance. The daily clang-analyzer scan hasn’t found a problem in a long time and the Coverity once-every-few-weeks occasionally finds something suspicious but we always fix those immediately.
https://daniel.haxx.se/blog/2016/11/23/curl-security-audit/
Было бы интересно, наверное, посмотреть, найдёт ли там что-то PVS-Studio после такое основательной чистки. Да и сам проект достаточно «весомый», я бы сказал.
(в вашем списке упоминания cURL я не нашёл)
Да, это интересно. Надо будет посмотреть. спасибо.
Посмотрели. Эх, жаль. Не нашлось ничего достойного внимания.
Так это ж хорошо :)
Я бы ещё посмотрел, были ли бы обнаружены PVS-Studio ошибки, которые были найдены в процессе аудита. В том смысле, насколько PVS-Studio «конкурент» такому аудиту?
Сами уязвимости и их исправления можно найти здесь:
https://docs.google.com/document/d/17EvPM_LHJiOQPGC8cZ7nd2_7Hs7PIhrQqa7s9-pylm0/edit
(double free, OOB write, integer truncation, ...)
Сами уязвимости и их исправления можно найти здесь:
https://docs.google.com/document/d/17EvPM_LHJiOQPGC8cZ7nd2_7Hs7PIhrQqa7s9-pylm0/edit
(double free, OOB write, integer truncation, ...)
Ещё один весьма популярный проект, не попавший на ваши радары — SQLite.
Или же он фигурирует в списке под «Various small projects we didn't write about»?
И ещё, как заинтересованный пользователь, хотел бы предложить вам проверить KeePass (http://keepass.info)
Или же он фигурирует в списке под «Various small projects we didn't write about»?
И ещё, как заинтересованный пользователь, хотел бы предложить вам проверить KeePass (http://keepass.info)
Исходя из кода, некэшированный URL запрос (net::URLRequest *request) будет завершен также, как и кэшированный.
В одном слуае вернет true в другом false.
правка автора статьи всегда вернет false.
А доступны ли все результаты анализа? Я сообщил о Вашей статье разработчикам Chromium, которых знаю по LLVM/Clang.
Ошибку в action_wait.cc сразу поправили:
https://codereview.chromium.org/2453783002
https://codereview.chromium.org/2453783002
А был ли у вас кейс «пользуемся опенсорс продуктом, но мешает какой-нибудь противный баг, проверяем анализатором, находим баг, исправляем, компилим и пользуемся дальше, уже без бага»?
Обращение ко всем пользователям Linux-версии PVS-Studio 6.10.
WARNING! Хочу обратить внимание, что сырой лог, полученный сразу после проверки использовать нельзя! Он не предназначен для просмотра и служит только как источник данных для программы plog-converter.
К нам стало приходить большое количество писем, что результатами работы PVS-Studio пользоваться невозможно. Программисты получают огромный файл, с тысячами одинаковых сообщений на один заголовочный *.h файл и прочим мусором. Мучаются, жалуются. Другие, наверное, не жалуются, а молча теряют интерес к PVS-Studio.
Эти файлы и не предназначены для просмотра. Для преобразования их в «человеческий» формат служит утилита plog-converter, описанная в документации. Эта утилита не только преобразует лог, но и удаляет в нём дубликаты для h-файлов, фильтрует сообщения и так далее. Например, есть смысл начать изучение отчета с предупреждений общего назначения первого и второго уровня (ключ -a GA:1,2). Это очень важно, так как иначе программист просто утонет в сообщениях.
В следующей версии, мы планируем изменить изначального формат лога, чтобы было понятно, что это некий бинарный формат и он не предназначен для просмотра. Это должно подсказать программисту, что с этим файлом надо ещё что-то сделать и он, продолжив в чтение документации, будет узнавать про plog-converter.
А сразу нормальный результат выдать нельзя?
Можно, но есть две причины так не делать.
1. Скорость. Сейчас при параллельном анализе каждый процесс просто пишет в конец файла. Таким образом файл блокируется только для однократной записи. Это быстро и разные анализаторы друг друга почти никогда не ждут. Если сразу фильтровать дубликаты для h-файлов, каждый раз нужно делать поиск по файлу. Это значительно дольше и анализаторы начнут ждать друг друга. Начнутся простои и время анализа увеличится.
2. Наличие полного списка всех сообщений позволяет делать разные выборки без необходимости заново проводить полный анализ. Т.е. посмотрели некий отчёт, поняли, что не хотим смотреть диагностики 3-его уровня. Поправили настройки, запустили plog-converter и через минуту имеем новый отчёт. Иначе пришлось бы ждать час пока вновь будет анализироваться проект
1. Скорость. Сейчас при параллельном анализе каждый процесс просто пишет в конец файла. Таким образом файл блокируется только для однократной записи. Это быстро и разные анализаторы друг друга почти никогда не ждут. Если сразу фильтровать дубликаты для h-файлов, каждый раз нужно делать поиск по файлу. Это значительно дольше и анализаторы начнут ждать друг друга. Начнутся простои и время анализа увеличится.
2. Наличие полного списка всех сообщений позволяет делать разные выборки без необходимости заново проводить полный анализ. Т.е. посмотрели некий отчёт, поняли, что не хотим смотреть диагностики 3-его уровня. Поправили настройки, запустили plog-converter и через минуту имеем новый отчёт. Иначе пришлось бы ждать час пока вновь будет анализироваться проект
(del)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идем на рекорд: пятая проверка Chromium