![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Удачное начало нового года или программистская гинекология.
"Сначала мы себе создаем проблемы, а потом их героически решаем."
Проявился, значит, в одном из сервисов, призванных работать 24/7, странный баг.
Все работает, никаких исключений, никаких признаков ничего плохого - но данные в базу не попадают. Появляется ну раз в месяц, может быть. Бесил, ибо был необъясним.
Добавил в сервис консоль удаленного управления, через телнет. Запряг весь наш саппорт при таких симптомах ничего не делать, кроме поднимания меня из гроба.
И вот сегодня как раз удачно сошлись звезды: опять баг, саппорт меня саммонил, у клиента нормальный сервак, сервис обновлен, консоль есть, можно спокойно изучать.
Включил консолью всю отладку, сижу втыкаю в DebugView/OutputDebugString, параллельно рассматривая код.
И вижу странное: все работает, кроме функции которая скидывает данные из расчетного кэша в БД. А функция, в целях снижения нагрузки на БД окружена таймером, который разрешает ей работать не чаще чем раз в определенное время, обычно 15 секунд. И, что характерно - реализовано это на GetTickCount, который хоть и склонен к переполнению, но при адекватной реализации это не мешает. А реализация там, ВНЕЗАПНО, неадекватная - два обращения к GetTickCount, вместо одного.
Смотрю значение GetTickCount - 1.25 дня. Смотрю данные - последний раз пришли в 7 часов утра. Туплю. Потом доходит - 7 часов утра ВЧЕРА, т.е. 1.25 дня назад. С приездом вас, называется.
Сервис останавливать нежелательно - надо бы и данные скинуть в базу, а то потом придется делать немного хитроватую процедуру их повторной передачи.
Значит, что я делаю:
1) Достаю строго нужную версию сервиса из SVN.
2) Собираю с отладочной информацией.
3) Копирую файлы отладочной информации клиенту рядом с его работающим сервисом.
4) Ставлю Debugging tools for Windows
5) Подключаюсь к сервису
6) Ставлю bp на нужный метод.
7) Ловлю вызов.
8) Дохожу до реализации if в виде cmp edx, eax / jbe ...
9) Меняю значение регистра edx на правильное, метод идет работать как положено.
10) Profit. Данные скинулись в базу. Переменная установилась в кошерное значение. Еще есть 49 дней до следующего переполнения, можно успеть починить исходники.
Проявился, значит, в одном из сервисов, призванных работать 24/7, странный баг.
Все работает, никаких исключений, никаких признаков ничего плохого - но данные в базу не попадают. Появляется ну раз в месяц, может быть. Бесил, ибо был необъясним.
Добавил в сервис консоль удаленного управления, через телнет. Запряг весь наш саппорт при таких симптомах ничего не делать, кроме поднимания меня из гроба.
И вот сегодня как раз удачно сошлись звезды: опять баг, саппорт меня саммонил, у клиента нормальный сервак, сервис обновлен, консоль есть, можно спокойно изучать.
Включил консолью всю отладку, сижу втыкаю в DebugView/OutputDebugString, параллельно рассматривая код.
И вижу странное: все работает, кроме функции которая скидывает данные из расчетного кэша в БД. А функция, в целях снижения нагрузки на БД окружена таймером, который разрешает ей работать не чаще чем раз в определенное время, обычно 15 секунд. И, что характерно - реализовано это на GetTickCount, который хоть и склонен к переполнению, но при адекватной реализации это не мешает. А реализация там, ВНЕЗАПНО, неадекватная - два обращения к GetTickCount, вместо одного.
Смотрю значение GetTickCount - 1.25 дня. Смотрю данные - последний раз пришли в 7 часов утра. Туплю. Потом доходит - 7 часов утра ВЧЕРА, т.е. 1.25 дня назад. С приездом вас, называется.
Сервис останавливать нежелательно - надо бы и данные скинуть в базу, а то потом придется делать немного хитроватую процедуру их повторной передачи.
Значит, что я делаю:
1) Достаю строго нужную версию сервиса из SVN.
2) Собираю с отладочной информацией.
3) Копирую файлы отладочной информации клиенту рядом с его работающим сервисом.
4) Ставлю Debugging tools for Windows
5) Подключаюсь к сервису
6) Ставлю bp на нужный метод.
7) Ловлю вызов.
8) Дохожу до реализации if в виде cmp edx, eax / jbe ...
9) Меняю значение регистра edx на правильное, метод идет работать как положено.
10) Profit. Данные скинулись в базу. Переменная установилась в кошерное значение. Еще есть 49 дней до следующего переполнения, можно успеть починить исходники.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Кстати, если вдруг нет отладочной информацыи -- то сравнительное удобство командной строки только возрастает. То есть подобную задачу я, скорее всего, решыл бы довольно быстро и без debug symbols.
А вот собрать так, чтобы отладочная информацыя попала -- т.е. как минимум та жэ версия gdb, libgcc и скриптов линкера -- это выглядит фантастикой. Я не пробовал, но выглядит. Так что отладочные символы всегда надо спасать при релизах. И -dbg пакеты в Debian -- отнюдь не блаж, а рабочий инструмент сисадмина.
no subject