CoLaboratory: Статический анализ в С++ и анализ производительности HD

CoLaboratory: Статический анализ в С++ и анализ производительности
03:21:12
Обнаружено блокирование рекламы на сайте

Для существования нашего сайта необходим показ рекламы. Просим отнестись с пониманием и добавить сайт в список исключений вашей программы для блокировки рекламы (AdBlock и другие).

«Лаборатория Касперского» — одна из наиболее динамично развивающихся компаний в сфере информационной безопасности. Мы уверенно входим в четверку ведущих мировых производителей программных решений для защиты конечных пользователей.

Статический анализ в С++ и анализ производительности.

Авторы: Александр Нежельский, Евгений Буштырёв, Никита Какуев, Николай Дьяконов.24 мая 2016 года мы собрались в штаб-квартире «Лаборатории Касперского» на Водном Стадионе, чтобы обсудить статический анализ C++ кода и анализ производительности программ. Это первая из серии встреч CoLaboratory, посвященная разработке на C++. В числе прочего вы услышите, как сделать код пригодным для статического анализа, как бороться с ложными срабатываниями и как расширять функциональность Clang Static Analyzer за счет собственных проверок.Запись первого доклада «Статический анализ в С++»: Запись второго доклада «Основы перформанс-тестирования» доступна тут: Подробное описание мероприятия можно найти здесь: Презентации докладчиков можно скачать тут:Больше событий event-платформы CoLaboratory доступны на нашем сайте: Доклады и другие мероприятия серии CoLaboratory:Официальный сайт «Лаборатории Касперского» Читайте нас в социальных сетях:Facebook:…Vkontakte: Odnoklassniki: Мой Мир: Google+:…Twitter: Instagram: Ищите нас на форумах:Фан-клуб «Лаборатории Касперского»: Форум пользователей:?Читайте наши блоги:Блог Евгения Касперского Блог Kaspersky Daily Блог Securelist Блог Threat post Блог на Хабрахабре
RSS
dov udo
18:52
+2
Не плохая конференция, мне понравилось. Спасибо.
haoNoQ
19:18
42:50 — Clang Static Analyzer вполне себе даёт включать-выключать отдельные проверки очень избирательно по одной или группами: либо на низком уровне clang -cc1 -analyze -analyzer-checker=… -analyzer-disable-checker=… (сколько угодно в любом порядке), либо высокоуровнево scan-build -enable-checker… -disable-checker…

Хотя там неприятность в том, что иногда одни и те же чеккеры отвечают и за срабатывания анализатора, и за улучшение моделирования, и можно ненароком испортить качество других срабатываний.
haoNoQ
20:15
1:03:50 — Если бесит время анализа, то, видимо, удобнее всего его регулировать при помощи низкоуровневого параметра -analyzer-config max-nodes=N (это опция clang -cc1), где N по умолчанию емнип 150000 — это лимит на размера графа символьного выполнения. Если уменьшить в пять-десять раз, то вы потеряете процентов 10-20 срабатываний, но время анализа станет сравнимым со временем компиляции.
haoNoQ
20:18
+2
1:08:30 — Ой не, клангстатиканалайзеровый MallocChecker не тупо подсчитывает new-delete в теле функции. Он смотрит все пути выполнения, которые он, читая код, может вообразить, и ищет такие пути, на которых указатель, возвращённый оператором new (ну или функцией malloc) заведомо исчез из памяти — нигде больше в программе не хранится, и как только такой момент возникает — сразу кидает предупреждение. Это довольно умная схема, и если она чего-то не находит — то скорее из-за «количественной» сложности кода (symbolic execution штука гиперэкспоненциально тяжёлая, так что обозреть можно только небольшие фрагменты кода), может быть из-за недоступных определений вызываемых функций, из-за багов, чем из-за качественных проблем метода.
haoNoQ
20:19
1:09:48 Нет, не умеет кланг кодогенерить и анализировать одновременно, хотя вроде в рассылке обсуждали, и вроде не помню чтобы принципиальные причины были, может просто никому не понадобилось пока. Хотя… Может как раз внедряемый макрос __clang_analyzer__ является внятной причиной?
haoNoQ
20:20
+1
1:11:40 На самом деле ещё бы глянул кто-нибудь Ericsson/codechecker, который тоже представляет собой веб-мордочку для Clang Static Analyzer, но очень умную, с базами данных и размечалочками. И его вроде тоже собираются прямо в clang svn впилить, но я не смотрел пока.
haoNoQ
20:20
1:23:40 PthreadLockChecker в принципе довольно полезные вещи может находить, скажем на каком-то пути выполнения два мьютекса залочили в одном порядке, а разлочили в другом, то это подозрение на возможный дедлок. Но в целом это, пожалуй, лучшее что есть: чтобы реально изобразить многопоточное выполнение в статике — вроде не слышал.
Артём Коноплёв
20:26
+1
чтобы не прыгать на «мордокнигу»:
Александр Нежель
17:42
+1
Презентации докладчков доступны здесь:

Доклады вне трансляции (по отдельности) и в более высоком качестве можно посмотреть тут:
Ivan UIO
16:27
зачем первые 22 минуты пустых?