Поиск ошибок в проектах на основе Unreal Engine
В статическом анализаторе PVS-Studio начали появляться диагностические правила для выявления багов, специфичных для Unreal Engine проектов. Однако без сообщества разработчиков игр здесь не обойтись. Напишите нам про типовые паттерны ошибок, поиск которых хотелось бы автоматизировать.
Анализатор PVS-Studio хорошо выявляет распространённые паттерны опечаток, логические ошибки, потенциальные уязвимости и многое другое. Теперь взор команд, разрабатывающих PVS-Studio, обратился в сторону Unreal Engine.
Мы начали реализовывать диагностики для поиска ошибок, специфичных для проектов, построенных на этом игровом движке.
Первый пример. Появилось диагностическое правило, анализирующее классы, не унаследованные от типа UObject. Если в таком классе есть нестатическое поле в виде указателя на тип, унаследованный от UObject, то это неправильно.
class SomeClass
{
....
UObject *m_ptr;
....
};Сборщик мусора Unreal Engine может уничтожить объект, адресуемый указателем m_ptr. Подробнее про это диагностическое правило: V1100.
Второй пример. Выявляются сущности, несоответствующие соглашениям о наименованиях для проектов, основанных на Unreal Engine. Соответствие соглашениям требуется для корректной работы Unreal Header Tool:
- Имена классов, наследуемых от UObject, следует начинать с префикса 'U';
- Имена классов, наследуемых от AActor, следует начинать с префикса 'A';
- Имена классов, наследуемых от SWidget, следует начинать с префикса 'S';
- И так далее. Подробности см. в описании диагностического правила V1102 (войдёт в октябрьский релиз PVS-Studio 7.27).
Это только начало. Мы будем собирать паттерны подобных ошибок и реализовывать их выявление в анализаторе. Нюанс в том, что без помощи GameDev сообщества мы будем делать это очень медленно. Поскольку мы сами не разрабатываем игры, коллекционирование паттернов поначалу будет носить случайный характер.
Мы легко черпаем вдохновение для диагностик общего типа. В чём сложность с Unreal Engine?
Про ошибки общего плана достаточно много пишут в статьях, книгах. Их проще коллекционировать. Мы также собираем много идей при работе в поддержке с нашими пользователями.
Так же может сложиться и с UE-ориентированными диагностическими правилами. Пользователи будут находить ошибки и присылать идеи, что ещё можно искать. Нужно только подтолкнуть, запустить этот процесс. Поэтому и появилась эта заметка.
Пишите в комментариях идеи по поиску багов!
Приглашаю вспомнить и написать в комментариях, какие ошибки вы регулярно выявляете на code review, хотя их можно выявить автоматически. Собственно, ведь статический анализ — это своего рода автоматизированный обзор кода.
Мы ждём ваших интересных идей. Спасибо!
