Пять дней на исправление ошибки в два символа, или миф о всемогущих технологиях при разработке программ

30 Авг 2010

Автор: Евгений Рыжков

В этом блоге нередко можно почитать о том, как тот или иной программный инструмент, или технология разработки программ помогает делать меньше ошибок, быстрее их находить, легче исправлять. Все это конечно справедливо, но до сих пор нельзя отказываться от самого главного инструмента - мозга, так как заменить его не может ничто. Мой сегодняшний рассказ о программной ошибке, для исправления которой понадобились два символа и пять дней работы.

Однажды после выпуска новой версии статического анализатора кода PVS-Studio, к нам обратился пользователь, жалующийся на то, что наш инструмент не работает на его сложном проекте. Кстати хороший способ для разработчиков оценить полезность программы – если после очередного релиза вам приходит несколько писем с сообщением что что-то не работает и сломалось, то значит ваша программа нужна. Вернемся к программе. Итак, не работает – это значит не находит файлы для анализа. Сначала были вопросы про тип проекта, про установленные дополнительные плагины к Visual Studio. Выяснилось, что у пользователя установлен компилятор Intel C++ Compiler, но дело не в нем. Также у пользователя была установлена CUDA, но и это оказалось не причем. Кстати, проверка простенького демонстрационного проекта работала, хотя проверка вновь созданной пустой болванки проекта – уже не работала.

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

Под конец пятого дня после неоднократного запуска специальной отладочной версии с расставленными printf (ага, это к вопросу о printf vs новомодные крутые инструменты) выяснилось следующее. Наш анализатор для анализа файлов генерирует специальные cmd-скрипы, в которых есть строка вида:

cd e:\projects\mylib

то есть переход в папку проекта. А как раз в этой версии (предыдущая работала у пользователя нормально) мы сильно переписывали механизм генерации этих скриптов. У команды cd есть особенность – она не переходит в папку на другом диске, если не указать опцию "/d". То есть правильно должно быть так:

cd /d e:\projects\mylib

Этот ключ "/d" был в прошлой версии программы, но по ошибке и недосмотру был потерян в новой версии при переписывании. К сожалению, все тесты у нас запускались с того же системного диска, поэтому команда cd без опции "/d" отрабатывала нормально.

Причем для того, чтобы ошибка проявилась надо обязательно открыть проверяемый проект через Visual Studio (File->Open...). Если же открыть проект, выбрав sln-файл, то ошибка не проявлялась, так как при таком открытии рабочая папка совпадала с папкой, указываемой в команде cd скрипта. Поэтому повторить ошибку не удавалось довольно долго.

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

Какие можно выводы сделать из этой истории? Банальные, но начинающим программистам от этого они менее полезными не станут:

Если ваша программа не работает у пользователя, то не стоит винить установленные у него на компьютере программы типа CUDA или Intel C++ Compiler. Хотя и они бывают виноваты.
Даже если у вас приложение проходит пять разных типов тестов, то это не значит, что оно работает всегда и везде.
Никакой программный инструмент не сможет полностью заменить человеческий мозг. Увы.
Если пользователи вашей программы сами программисты, то вам повезло! Ну какие еще пользователи знают слова отладочная версия, дамп и прочее?