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 минуты пустых?

Новости

«СёрчИнформ FileAuditor» расширил контроль файловых серверов на Linux «СёрчИнформ SIEM» интегрирована с почтовым сервером RuPost Рынок DLP-систем в Центральной Азии: как законы о суверенитете данных стимулируют спрос на локальные решения «СёрчИнформ КИБ» расширил возможности «открытого контроля» для ПК на Linux «РИКИТЛАБ» представила новую модель техподдержки ИТ-инфраструктуры промышленных предприятий

«СёрчИнформ FileAuditor» расширил контроль файловых серверов на Linux


16 часов назад
«СёрчИнформ FileAuditor» расширил контроль файловых серверов на Linux
«СёрчИнформ FileAuditor» расширил контроль файловых серверов на Linux
«СёрчИнформ SIEM» интегрирована с почтовым сервером RuPost
«СёрчИнформ SIEM» интегрирована с почтовым сервером RuPost
Рынок DLP-систем в Центральной Азии: как законы о суверенитете данных стимулируют спрос на локальные решения
Рынок DLP-систем в Центральной Азии: как законы о суверенитете данных стимулируют спрос на локальные решения
«СёрчИнформ КИБ» расширил возможности «открытого контроля» для ПК на Linux
«СёрчИнформ КИБ» расширил возможности «открытого контроля» для ПК на Linux
«РИКИТЛАБ» представила новую модель техподдержки ИТ-инфраструктуры промышленных предприятий
«РИКИТЛАБ» представила новую модель техподдержки ИТ-инфраструктуры промышленных предприятий