Archive for September 2008

Рецепты отладки. Return в пустоту.

Сегодня речь пойдет про отладку некоторых проблемных событий, на которые я получаю частый ответ типа “а хз где сдохло, висим на нулевом адресе, stack frame нету, сделать ничего не могу”.
Continue reading ‘Рецепты отладки. Return в пустоту.’ »

Тяжела и неказиста жизнь GFX программиста

Сидел за компьютером, пытался оптимизировать наш проект. Аллоды Онлайн, проект в чем-то похож на WoW. Открытые пространства, террейн, в кадре полтысячи объектов на нем. Освещение в лайтмапах, Dx9. Вся эта красота жрет 40% времени в драйвере NVidia, 10% времени в D3D9.dll.

Руки опускаются – это говно, которое называется графикой на PC, невозможно оптимизировать. Под катом – плач и сожаления.

Continue reading ‘Тяжела и неказиста жизнь GFX программиста’ »

Хромающая диагностика

Снова в который уже раз проблема с тулсетом требует длительного выяснения, пересборки в дебаге и в результате оказывается, что там стоит гадский ассерт, который в релизной конфигурации, ессно, вырезался, а программа далее успешно зависает (ну или падает – зависит от фазы луны).
В который уже раз буду банальным – грамотная диагностика – залог успешности программы, особенно если речь идет о тулсете. Не невидимые в релизе ассерты, которые половиной программистов не ставятся вообще, а половиной – ставятся абы как, а правильная и четкая диагностика, которая с одной стороны, может защитить приложение от сбоев в какой-то его части, а с другой стороны, позволяет сразу получить понятное описание проблемы.

Как то во времена Американ Чоппера, когды мы в Крейте жили целыми месяцами, был такой случай. Я случайно оказался дома, чтобы поспать 4 законных часа, как меня телефонным звонком разбудил Стас Богданов, который спросил: ”Дима, а что такое Scene index must be zero blababla….? Никогда такого не встречал”. Мне потребовалось несколько секунд, чтобы понять, какая именно дьявольская комбинация аргументов командной строки и описаний в текстовом файле могла привести к таким последствиям, и вопрос был дистанционно и мгновенно решен. Эта строка была написана за год до описываемых событий и никогда до и никогда после этого в процессе обработки уровня не встречалась.

Не спорю, что писать логи – это долгое занятие (хотя отладка – еще более долгое). Не спорю, что далеко не все программисты в состоянии вспомнить, что за строчка была написана за год до события. Но писать циничное a = malloc(); assert(a); – это то же самое, как если бы написать a = random(); assert(a != 0.5). То есть мы ассертируем стандартное поведение функции, которое описано в справочнике.

Пример с маллоком далеко не единственный. Конкретно в данном случае срубилось необработанное CreateProcess(). Вообще я стараюсь придерживаться следующего правила: нужно ассертировать программистские ошибки. Валидные (описанные в MSDN) коды возврата функций API, предположения о формате или синтаксисе файлов, наличия файлов на диске, аргументов командной строки, нажимаемых пользователем кнопок – никакие такие действия не могут ассертироваться, они должны корректно обрабатываться и еще сохранять данные в лог, чтобы можно было разобраться, что произошло, даже в полвторого ночи.

try catch, кстати, тоже не панацея – во первых, он тоже не провоцирует писать логи (за исключением того, что м.б. “Что-то упало внутри этого блока try”, а вто вторых, им еще надо грамотно уметь воспользоваться.