avva | разбор полётов

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

Будет интересно программистам, знающим Перл (и не знающим тоже, впрочем).

Баг включался вот при каких обстоятельствах. У кого-то на компьютере неправильно проставлена дата. Но не просто в будущем или в прошлом (это, кстати, бывает очень часто), а настолько всё плохо, что бывают невозможные даты. Скажем, 31-е апреля или 30-е февраля.

Когда сервер ЖЖ принимает дату записи от клиента (или от джаваскрипта пользовательского браузера), он в принципе должен проверять её корректность. В прошлом или в будущем она вполне может быть, это не запрещается, но невозможной быть не должна. Эта провека не срабатывала (почему? ещё проверяется), и невозможная дата попадала в базу данных. Это, однако, до поры до времени никому не мешало. Всё равно ленты друзей, например, сортируются по серверной дате, а не той, которую даёт клиент. Дата, которую даёт клиент, используется только для сортировки главной страницы журнала, а также календарных страниц; и ещё её показывают всюду, ясно.

Итак, в процессе постройки ленты друзей эти даты не используются для сортировки; но они всё равно обрабатываются для показа. В процессе обработки они переводятся из внутреннего формата базы данных MySQL в некий другой формат. Для этого вызывается перловская функция Time::Local::timegm(), которая берёт набор чисел - год, месяц, день, час, минута, секунда - и возвращает число секунд, прошедшее с полуночи первого января 1970-го года до этого времени (так называемое Unix epoch time). Потом это число в свою очередь преобразовывается в нужный формат, позже.

Что случилось? Вчера все серверы, обслуживающие запросы ЖЖ, были все переведены с версии Перла 5.6 на версию 5.8. В обоих версиях Перла фунцкия timegm(), если ей не нравятся переданные ей данные, "умирает" с ошибкой. Однако в перле 5.6 проверка правильности даты, в частности числа дня в месяце, несколько, гм, упрощённая:

croak "Day '$_[3]' out of range 1..31" if $_[3] > 31 || $_[3] < 1;

(т.е. число, в данном случае $_[3], проверяется только на >31 и <1)

В перле 5.8 проверку ужесточили:

my $md = $MonthDays[$month];
++$md unless $month != 1 or $year % 4 or !($year % 400);
croak "Day '$mday' out of range 1..$md"   if $mday  > $md  or $mday  < 1;

Т.е. число $mday сравнивается не с 31, а с правильной предельной датой для данного месяца, хранящейся в массиве MonthDays. И даже високосные годы учтены (вторая строка).

Поэтому внезапно вчера Перл начал умирать, когда ему передают невозможные даты записей типа 31-го апреля. Т.к. со стороны кода ЖЖ никто такую возможность не учитывал, код ЖЖ в таком случае тоже умирал и обработчик самой внешней оболочки ловил это падение, не понимал, в чём дело, и выдавал пользователю невнятную ошибку вида "Technical difficulties".

Конечно, перед тем как перевести серверы на Perl 5.8, всё проверяли, но эту проблему не отловили, т.к. настолько неверные даты встречаются очень-очень редко (зато когда всё же встречаются, то сразу хлопаются френд-ленты всех друзей данного юзера или сообщества, поэтому очень заметно). Собственно, довольно долгое время часть серверов ЖЖ, примерно четверть, бежали под Perl 5.8, и у них случалась эта проблема, значит; но т.к. пользователи, после нажатия Reload в браузере, попадали на другой случайный сервер, который с большой вероятностью был Perl 5.6 и всё показывал, они считали, что это просто проблемы с нагрузкой или чем-нибудь таким.

Flat | Top-Level Comments Only

From:

alesk.livejournal.com

Какой красивый баг, однако

From:

squadette.livejournal.com

понятно, почему от пользователя прячут gory details, но зачем от девелопера её прятать?

у нас, например, работает мониторилка error_log'ов, которая их шлёт в список рассылки, и если туда что-то приходит, то этот вопрос рассматривается и фиксится. Чрезвычайно полезно.

From:

avva.livejournal.com

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

msk_consumer, кскати. Сама юзерша ни в чём не виновата. Ну, подумаешь, живёт в 2010-м году. Гостья из будущего ;)) выдавалась ошибка [Error: Day '31' out of range 1..30 at /home/lj/cgi-bin/ljlib.pl line 2092 @ w30], которая помогла мне очень быстро найти проблему. Трудность была в том, чтобы эту запись найти, т.к. календари не работали итп.

Те URLи, которые не .bml/.html (ленты, календари, главные страницы дневников) обрабатываются по-другому, через довольно древний интерфейс, который несколько раз латали, и который плохо сохраняет дополнительную информацию (кроме самого текста страницы), возвращаясь снизу вверх. На самом деле ошибки всё равно идут в базу данных. Но их всегда так много (и некоторые из них вполне рутинные типа несуществующих URLей из-за того, что кто-то ссылку испортил или ещё чего), что трудно отличить зерна от плевел. А когда появляется новый реальный баг, из-за уровня траффика ошибки, с ним связанные, даже если бы их можно было отделить от остальных, текут таким густым потоком, что никакая рассылка не выдержит. Нужно что-то умное, что умело бы группировать ошибки и отсекать мусор, никто не хочет это писать, наверное.

(...)

разбор полётов

Page Summary

Style Credit

Expand Cut Tags