Ошибки программистов C++ — это отдельный вид искусства, вроде бы простой язык, но стоит отвлечься на чашечку кофе, как компилятор начинает вываливать простыню ворнингов пополам с ошибками, и иногда это больше похоже на древнеегипетские письмена, чем на нормальный выхлоп. Вы наверное и сами не раз сталкивались с разыменованием nullptr или перепутали (= и ==) по недосмотру. Часто причиной ошибкой является лень или невнимательность, или усталость - не зря появились суеверия "не комитить в пятницу вечером", "не кодить в состоянии изменного сознания" или "избегать кода под кофейным угаром", ну это когда три-четыре кружечки кофе навернул и пошел нести добрый код направо и налево.

Вообще статья планировалась про то как можно поиздеваться над switch оператором - была у меня запись разговора с одного питерского митапа, проходившего несколько лет назад и где присутствующим предложили написать "невозможный", но работающий код со switch. И вот в поисках этой записи я наткнулся на файл с описанием "пятничных" багов и комитов, которые бы в трезвом уме посреди недели врядли бы проскочили в мастер. А еще была статья тоже про ошибки "Федя, дичь", где уважаемый хабрачитатель угадывал причину разных ошибок, явных или не очень. Поэтому я решил продолжить в том же стиле, вопрос - ответ, а вам предлагаю также поучаствовать в отгадывании возможных причин. Все примеры из реальных проектов, игр, движков и пятничных комитов.

C++ не прощает ошибок, но именно в этом его "шарм". В большинстве приведенных примеров сохранен стиль и названия параметров, только немного подчищены коментарии, дабы не палить контору.

0х10

Игнорирование правил разработки и изобретение велосипедов в большинстве случаев заканчиваются багом. Так и тут, движок иногда крашился в при отрисовке UI виджетов, но чаще просто портил другие виджеты, которые были полностью сделаны на POD типах.

std::vector<int> Widget::DrawElements(Element* p, int n) {
    std::vector<int> result;
    result.reserve(n);
    for (int i = 0; i < n; ++i) {
    	bool r = DrawElement(p[i]);
        result.push_back(r);
    }
    ...
    return result;
}

void Widget::Draw(int m) {
    constexpr int n = 10;
    Element a[n] = {}; // локальный буффер, связано с отложенным рендером виджетов
    // copy elements
    // ...
    DrawElements(a, m);   
    // ...
}

0x11

При портировании движка Dagor на платформу nintendo switch пришлось сделать прослойку для работы с файловой системой. После очередной пятницы игра стала крашиться через несколько загрузок в рандомных местах с ООМ (out of memory), а причина оказалось всего в одной строчке. Тут должно быть просто.

void OsFile::ropen(const NxString &name) {
    NxFile f = NxFileOpen(name, "r");
    // ...
    if (something) return;   
    // ...
    NxFileClose(f);
}

0x12

В отдел пришел новичок, ему дали мелкие баги для ознакомления с кодовой базой. А чтобы было не так скучно разрешили немного рефакторить код в дев ветке, дабы была история комитов и понимание как продвигается онбординг. Во вторник от QA прилетает претензия, что редактор стал на порядок медленее грузить уровни - мелкие еще нормально грузит, а большие минут по двадцать стал прям. Причем только у QA отдела, у всех остальных все норм. Тут надо немного пояснить, инструмент для тестирования которым пользовались, заодно и форматировал конфиги уровней перед апрувом. QA пострадали денек, и решили все таки написать программерам, которые по горячим следам нашли вот такое:

void lower(xstring &s) {
    for (int i = 0; i < strlen(s); ++i) {
    	s[i] = tolower(s[i]);
    }
}

for (int i = 0, size = (int)strlen(s); i < size; ++i) {
	s[i] = tolower(s[i]);
}

0х13

Отправили очередной патч для бокса, а он не проходит тесты. Майкрософт сначала просто морозились и реджектили билды, потом прислали комплайнс на забытые сенситив данные. Какие блин такие забытые?

Subject: Urgent Security Alert: Unused Encryption Keys Found in Memory
Hey Team,
Hope you’re all doing great! During our recent testing sessions, we came across a serious issue regarding some leftover encryption keys in memory tied to our Secure Layered Login (SLL) system. It looks like these keys were overlooked, and if we don’t deal with them quickly, they could potentially expose sensitive data to unauthorized access, approval pipeline will be moved to pre-stage policy after one week.

Было: CL125332
void XBL::UserLogin::requestKey() {
    char secretKeyPwa[MAX];
    // ...
    // something work
    // ...
    memset(secretKeyPwa, 0, sizeof buffer);
    ENSURE(secretKeyPwa[0] == 0);
}
<->
Cтало: СL127499
void XBL::UserLogin::requestKey() {
    char secretKeyPwa[MAX];
    // ...
    // something work
    // ...
    memset(secretKeyPwa, 0, sizeof buffer);
    assert(secretKeyPwa[0] == 0);
}

0x14

Дивное утро понедельника, от дизайнеров прилетает баг, что сущность на уровне перестала определять у себя наличие правой и левой руки в скелете, оттуда доставались кости и локаторы, чтобы цеплять руки к соотвествующим места на оружии. Или определяла, что руки есть но путала их местами из-за чего возникали различные графические глюки, вроде левой руки на прикладе и т.д.

using namespace std;

struct UnitComponent {
    string name;
    int number;

    UnitComponent(string nm, int num) : name(nm), number(num) {}
    virtual bool operator==(const UnitComponent& a) const {
        return name == a.name && number == a.number;
    }
    // ...
};

struct UnitHand : public UnitComponent {
    bool left_hand;

    UnitHand(string nm, int num, char ch) : UnitComponent(nm, num), left_hand(ch) {}
    virtual bool operator==(const UnitHand& a) const {
        return UnitComponent::operator==(a) && left_hand == a.left_hand;
    }
    // ...
};

int main() {
    UnitComponent comp{ "test", 1 };
    UnitHand hand{ "test", 1, true };
    printf("comp == hand (%d)\n", comp == hand);    // compares name and number, ignores unit's left_hand
    UnitHand leg{ "test", 1, false };
    printf("hand == leg (%d)\n", hand == leg);   // compares name, number, and left_hand
    UnitComponent &hand_ref = hand;
    UnitComponent &leg_ref = leg;
    printf("hand_ref == leg_ref (%d)\n", hand_ref == leg_ref);  // ???

    return 0;
}

0x15

Бывает что ошибаются даже рокстары-рендерщики, которые в погоне за перфом, в пятницу вечером пишут всякое. А потом утром в понедельник в аврале ревертят стопицот изменений. В теории, пулл текстур должен был содержать пустые текстуры, которые бы оттуда забирались по мере создания объектов. Но что-то пошло не так и движок крашился уже на первом обращении к текстуре.

struct TextureBase {
    virtual void update() = 0;
    std::shared_ptr<int> sp;
};

struct TextureDX12 : public TextureBase {
    void update() override {}
};

void init(std::vector<TextureDX12> &a) {
    memset(a.data(), 0, sizeof(TextureDX12) * a.size());
}

0х16

Еще один пример невнимательности или случайное стечение обстоятельств, игре не хватало памяти на iPhone6, где пришлось урезать пул эффектов. В итоге на загруженных сценах получили графические артефакты в случайных местах. Но что забавно игра не крашилась, а порою эти баги и вообще не были замечены.

std::array<Particle, 2048> particles;
std::array<ParticleShader, 2048> shaders;

void updateEffects() {
    for (int i = 0, size = particles.size(); i < size; ++i) {
        //
        if (/* something */) ++i; 
        //
        ... some logic
    }
}

0х17

Напортачить можно даже в трех строчках, особенно если код стал многопоточным, в некоторых случаях отдельный юнит на сцене не двигался. Исследование бага показало, что Mover (это компонент, который отвечал за навигацию юнита по сцене) не получал апдейты, потому его не было в пуле муверов. Найдете ошибку?

Mover MoverPool::acquire() {
    static int init = 0;
    if (!init) {
        init = 1;
        create_pool();
    }

    return create_mover();
}

0х18

Вам может казаться что вы пофиксили проблему, но она возвращается через какое-то время. Например в этом простом баге иногда оставались лишние юниты на уровне, и движок ассертил об этом в логе. Но так как это все происходило на выгрузке уровня, то никто особо внимания не обращал. Человек, который был отвественный за эту систему придумал гениальный фикс. Когда переставали проходить тесты, он убирал или добавлял [volatile] и тесты начинали работать. В истории набралось с десяток комитов с такими фиксами.

[volatile] int free_slots = max_slots;

PathFinder* use()
{
    if (int n = free_slots--) return &finders[n];
}

0x19

Не совсем чтобы ошибка, но тоже попортила нервов порядком. Цена такого кода плюс несколько секунд на загрузке уровня. Немного информации по багу, у юнита есть компоненты, которые он на старте уровня подгружает в себя. Это может быть все, что угодно - рука, пушка, граната и какой-то другой аттач, система зрения и т.д. Таких компонетов у объектов могут быть десятки и сотни, и самих объектов на сцене тоже десятки и сотни - от декалей и луж, до машин и зданий.

std::map<ComponentId, Component> components;

bool ComponentVec::add(Component c) {
    ...

    if (components.find(c.id()) == components.end()) {
        components.insert({c.id(), c});
    }

    auto &compc = components[c.id()];
    ...
}

0х1а

А тут потихоньку текла память в менеджере частиц. Cможете найти виновника?

void Particle::CreateVerties(size_t p)
{
  std::shared_ptr<Vertex> ss(new Point[p * 3]); // each p is 3 vertex
  ....
}

0х1b

Обидная копипаста и обидная ошибка, которая была только в релизной сборке, движок проигрывал только первый звук из заданных для ентити. Но так, как обычно звуков было 1, редко 2 или больше, то ошибка долгое время так и жила себе.

int Entity::update_sounds(...)
{
  sounds.lock();
  sounds.commit();
  ...
  int i, size = sounds.size();
  ...
  for(i = 0; i < size; ++i); {
    sounds[i].pre_update(dt);
  }

  for(i = 0; i < size; ++i); {
    sounds[i].update(dt);
  }
  ...
  sounds.unlock();
}

0x1c

Еще одна частая, глупая, но плохо детектируемая ошибка. Моделькам назначается индекс шейдера, в большинстве случаев все работало, но в редких ситуациях модель рендерилась с графическими ошибками. Индекс шейдера не может быть больше 65к (размера кеша шейдеров). Ошибок не было на Ps5, но на Ps4 модели были с ошибками, игра при этом не крашилась, потому что рендер нормально отрабатывал отложенные шейдеры.

using AssignShaderCB = std::function<int()>;

void LoadModel() {
    BaseModel *model = ... 
    ...

    model.setShader([&] (Model* m) {
        const uint16_t shaderIndex = dummyShader();  
        return [&] () {
            shaderIndex = createShader(m);
            return shaderIndex;
        };
    });
}

0x1d

А тут было какое-то дикое стечение обстоятельств, луна не в той фазе, солнечная буря и шабаш ведьм в соседнем кабинете. Но код тесты прошел и даже какое-то время работал.

void BaseBehavior::ChaseEnemy(Human *h) {
    ...
    HumanType enemy = h->type();
    if ( enemy == HumanType::Corpse) {
        return;
    }

    if ( (enemy =! HumanType::Friend) || (enemy == HumanType::Follower)) {
        ...
    }
}

0x1e

В одном достаточно известном движке, долгое время жила своя функция перевода числа в хекс, видимо из коробки не устраивала скоростью или кодстайлом. Пока кто-то из мейнтейнеров не решил в порыве необузданного рефакторинга, что нулей в этой функции слишком много и залил этот комит в обход тестов, ну а че - изменения то самые банальные.

до "фикса"
const char buffer[] = "abcdef\0000123456789";

после "фикса"
const char buffer[] = "abcdef\0123456789";

0x1f

Сложный, эта функция использовалась в известном физ движке для поиска произвольного объема, заданного несколькими плоскостями, потенциально любым количеством плоскостей. Работала отлично, если плоскостей было меньше 16, и могла упасть если было больше. Должна работать быстро, потому что часто вызвалась в рантайме для проверок коллизий между объектами.

// NOTE! convex volume created in local space, you need apply xform from owner for correct world positions
template<typename T, typename E, typename V>
inline bool convex_volume_from_planes(const T &clip_planes, E &out_edges, V *out_vertices) {
    const u32 num_planes        = clip_planes.size();
    ...

    for (u32 i = 0; i < num_planes; ++i) {
        pair<vec, vec> * plane_egdes = alloca (16 * sizeof(vec) * 2);
        u32 next_plane_start_index = out_vertices ? 0 : (i + 1); // if we want to collect tris from planes, it should check all intersections
                                                                 // if we need only edges we can skip some checks, because edges was found on previous step
        for (u32 j = next_plane_start_index; j < num_planes; ++j) {
            vec line_orig, line_dir;
            ...

            vec *plane_vectices = alloca(sizeof(vec) * 3); // maybe expanded to 12 later
            ...
        }
    }
}

На этом всё! Всем безбажных тикетов.