Освобождение в errdefer дало утечку на успешном пути

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

1. Успешный путь под std.testing.allocator. Именно он нашёл утечку у why17, и он проверяет каждый defer.
2. Пути с ошибкой, где поверх стоит std.testing.FailingAllocator, настроенный отказать на первом выделении, потом на втором и так далее, и каждый прогон тоже проверяется на утечки. Вот он проверяет errdefer.

Функции, где есть и то и другое, нужны оба, а второму столько прогонов, сколько в функции выделений. До запуска стоит записать число выделений на вызов, какими из них после успеха владеет вызывающий и на каком по счёту отказе должен сработать какой errdefer. С этой функцией ни один из прогонов пока не запускал.

Сначала назовите владельца после успешного возврата, потом выбирайте оператор. Этот порядок работает в любом языке с ключевым словом для очистки и работает без него.

В Odin, на котором я пишу чаще, чем на Zig, есть только defer, а условное освобождение записывается как defer if cond { ... }, и условие на виду.

Практическое следствие касается документации. Функция, у которой освобождение стоит в errdefer, на успехе передаёт владение, поэтому в её документирующем комментарии должно быть сказано, что результат освобождает вызывающий и каким аллокатором. Без этой строки узнать это можно, только прочитав код очистки.

Прошёлся по остальному файлу в порядке, который предложил nullbyte. Пять errdefer. Четыре на успехе передают память вызывающему, и теперь в их комментариях это сказано вместе с аллокатором. Пятый освобождал временную хеш-таблицу, которую функция строит и выбрасывает. Это была ошибка из исходного поста, и ни один тест её не задел, потому что эта ветка выполняется только на входе с повторяющимися ключами. Теперь там defer.

Потом я прогнал цикл с отказами, который описал trial27. std.testing.FailingAllocator с fail_index от 0 до числа выделений в функции, и каждый прогон под проверкой утечек. После аудита я ничего не ждал. Индекс 1 дал утечку.

const keys = try allocator.alloc(u32, n);
const vals = try allocator.alloc(u32, n);
errdefer allocator.free(keys);
errdefer allocator.free(vals);

Аудит читал каждый errdefer и спрашивал, кто владеет памятью после успеха, и все четыре ответа были верны. Он ни разу не спросил, когда каждый из них регистрируется. Если второй alloc падает, его try возвращает ошибку раньше, чем появится первый errdefer, и keys утекает на том пути, который аудит считал закрытым. Исправление в том, чтобы ставить каждый errdefer сразу под выделением, которое он закрывает.

Цикл с отказывающим аллокатором теперь лежит в тестовом файле, по прогону на каждое выделение, и в следующий раз при таком аудите он пойдёт первым.