Концептуальное
от ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
skif_by:
>Дядька разбирался с индусским кодом
>Полдня постил в твиттер фотки с подавления восстания сипаев
skif_by:>Дядька разбирался с индусским кодом
>Полдня постил в твиттер фотки с подавления восстания сипаев
2012-01-04
Удачное начало нового года или программистская гинекология.
"Сначала мы себе создаем проблемы, а потом их героически решаем."
Проявился, значит, в одном из сервисов, призванных работать 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 дней до следующего переполнения, можно успеть починить исходники.
Псения псто
Большая энциклопедия раввината
Часть 2. Общение в интернетах
Глава 3. Основы троллинга
Раздел 2. Как заставить собеседника разговаривать с голосами в его голове.
Раздел 3. Как заставить собеседника разговаривать с голосами в вашей голове без вашего участия.
Раздел 4. Основы псения с использованием двойных и тройных стандартов
...
Приложение А. Список тем, вызывающих баттхерт.
Часть 2. Общение в интернетах
Глава 3. Основы троллинга
Раздел 2. Как заставить собеседника разговаривать с голосами в его голове.
Раздел 3. Как заставить собеседника разговаривать с голосами в вашей голове без вашего участия.
Раздел 4. Основы псения с использованием двойных и тройных стандартов
...
Приложение А. Список тем, вызывающих баттхерт.
О учете чеков и анальной бухгалтерии
Не веду подробный учет чеков, потому что неудобно вводить.
Может взять какой-нибудь опенсорсный OCR и склепать сканилку чеков, заодно мозг засушу как следует?
Может взять какой-нибудь опенсорсный OCR и склепать сканилку чеков, заодно мозг засушу как следует?