k001
k001
:...
k001 [userpic]
история бага

Уже написал по-английски, теперь попытаюсь по-русски рассказать историю, как OpenVZ team пофиксила один малюсенький баг в линуксовом ядре.

У нас в OpenVZ есть такая подсистема -- beancounters, это, грубо говоря, набор счётчиков и лимитов на всякие ресурсы. У каждой VE есть свои лимиты и счётчики (которые показывают текущее потребление ресурсов). Когда VE останавливается, счётчики должны приходить к нулевым значениям. Если не приходят -- где-то что-то ликает, течёт, то бишь, где-то кто-то что-то взял, а потом забыл отдать.

Так вот, три месяца назад команда тестеров обнаружила, что параметр kmemsize.held (который отвечает за память ядра, использованную для VE) после остановки одного ВЕ остался 78 байт (что несколько больше нуля). Значит, утекло 78 байт ядерной памяти.

Хорошо, что у нас в бинкаунтерах есть дебаг, который показывает, что именно утекло. Утекла одна struct user. Баг воспроизвести никак не удалось, поэтому его на время отложили, однако, багрепорт не закрыли.

Через какое-то время Паша к нему вернулся и понял, что единственный способ найти баг -- это прогрепать исходники на те места, где берутся и освобождаются struct user, и глазуально проверить логику всех тех мест. На это у него ушло полдня -- проверив практически всё, он нашёл место, где при некоторых условиях ссылка на объект struct user теряется.

Дальше уже проще -- написать код, воспроизводящий те самые условия. Убедиться, что течёт. Написать фикс (однострочный, кстати). Убедиться, что починил. Отправить патч и описание в LKML.

Что тут интересного:
1. Эндрю Мортон поинтересовался, как это так, откуда мы находим столько багов (наших патчей в ядро попало примерно 300 за последний год -- это почти всё багфиксы).
2. В данном случае помогли наши бинкаунтеры -- если б не они, хрен бы кто заметил утечку ядерной памяти смешным размером в 78 байт.
3. В данном случае также помогло упорство членов кернель тима (конкретно, Паши) -- они никогда не закрывают баги просто так, всегда докапываясь до причин (в большинстве случаев это удаётся, но бывают, правда, и "висяки").

Вот так. За каждым багом стоит, как правило, интересная история, но ту историю, как правило, никто не знает.

Comments

За каждым багом как правило ДВЕ истории. Одна - как появился баг, а вторая - как появился фикс :)

Спасибо, было весело. Пошел втащу патч к нам в ядро.

За каждым багом как правило ДВЕ истории. Одна — как появился баг, а вторая — как появился фикс :)


Тогда уж три — как посадили, как нашли, как пофиксили. Иногда тестерская история «как нашли» бывает крайне занимательной.

А бывает не менее интересная история "как контрибутор из пользователя выбивал описание бага и условий его воспроизведения"... Я в таких поучаствовал раз 50.

*завидуще вздыхая* какая у некоторых жизнь интересная.. я, кстати, абсолютно серьезно, в смысле - не издеваюсь, а реально завидую.

>однако, багрепорт не закрыли.
Вот это, в совокупности с "вернулся" есть _правильно_ :)

стараемся никогда без причины не закрывать.

(Anonymous)

глазуально != визуально? :)

offtopic

вы эта. "с ответным визитом" ко мне на дачу, в баню, не изволите?

Re: offtopic

Оу! sounds cool. Когда?

Re: offtopic

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

А сколько у вас кернель-девелоперов?

чуть более десяти

Ё! Молодцы! Мортон тоже, фантаст-писатель, жукодробилку русскую выдумал. :-)

"...some mysterious Russian bugfinding machine" - это порадовало :)

На самом деле он правильно интересуется и ваша организация процесса, видимо, лучше других и хорошо работает - причиной тому может быть как упорство в багодроблении, так и наличие хорошего источника данных - ващи bean counters.

Кстати, и за вас искренне рад по поводу уважения со стороны Мортона - так держать.

Интересная история. Спасибо.

> I was visualising some mysterious Russian bugfinding machine or
something.

ЖЖот:)

Да, мне эта mysterious russian bugfinding machine тоже тогда очень понравилась